geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <>
Subject Re: Release and Version Philosophy [Discussion]
Date Sun, 15 Jan 2006 18:42:58 GMT
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:


I'm fleshing out my ideas at


View raw message