Matt Hogstrom wrote, On 1/14/2006 9:02 PM:
I've seen several posts about the upcoming 1.0.x release and 1.1 and 2.0
etc. lately and I think its great that we're having these discussions.
I'd like to use this thread to aggregate people's thoughts about this
topic in a single thread for reference and clarification as we make
forward progress. So I'd like to clarify some terminology (at least
post what the terms mean to me) so we can make some meaningful plans for
our various efforts going forward.
This is a strawman so don't get too revved up. I think we need to
balance between structure and fluidity and I'm not sure exactly how to
do that; input welcome.
First, I see there is a structure for versioning like:
v.r.m[.f] where:
v = Version
r = Release
m = modification
f = fix (optional)
Version
-------
- Represents a significant set of improvements in Geronimo and a
definite milestone for our users.
- New features are introduced that may break compatibility and require
users to have to modify their existing applications that ran on previous
Versions. (Although we should strive to not force them to change
immediately but rather provide something like a V-1 or -2 compatibility
story. -2 Would be excellent but that might be too optimistic given the
rate of change.
- Things like JEE 5 would be found in a version change.
- Goes through a formal Release Candidate process for user feedback and
has broad coverage in terms of announcement. (Not just the Dev List)
- Release Candidates look something like Geronimo-2.0-RC1/2/3 etc.
Release
-------
- Can include significant new features / improvements.
- Should not break existing applications (lot's of traffic from users
saying something worked on M5 but doesn't on 1.0)
- Includes bug fixes and the like.
- It would be hard to justify moving to JEE 5 based on a release change.
- Has broad announcement
- Does not go through formal Release Candidate Process but does make
interim release attempts based on a dated binary release (ala
Geronimo-jetty-1.1-rc20060315)
Modification
------------
- Incremental release that builds on the goals of the V.R its based on.
- Can include new features
- Cannot disrupt existing application deployments
- Includes multiple bug fixes
Fix
---
- Focused release that addresses a specific critical bug.
- We're no where near this now but it would be nice to release specific
bug fixes and not whole server releases.
- An example of this would be something like a fix to the recent problem
Jetty uncovered related to security. A fix in this context would be a
simple packaging change to get the new Jetty Jar into the build and
wouldn't require a whole new server to be spun off.
Thoughts?
I see this as a two dimensional problem. How do we communicate to our
end users what can be expected and how we go about fulfilling those
expectations during our engineering effort. The initial touch point is
version numbers. I think that end users are only concerned with how
things are compatible when they look at version numbers, not the process
that was used to meet those compatibility expectations.
I think that you've mixed the two together, which is why you have a
Release and Modification.
I'm thinking:
- merge R and M, having that granularity seems confusing and I cannot
think of a compelling scenario that we would need to support to justify it.
- remove the last statement of "Release"; *all* code released, be it V,
R, M, or F, by Geronimo needs to go through a formal release candidates.
The nomenclature that I would use would be:
Major.Minor.Patch(-RC#)+
I'm fleshing out my ideas at
http://opensource.atlassian.com/confluence/oss/x/Wgs
Regards,
Alan
