geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: Release and Version Philosophy [Discussion]
Date Sun, 15 Jan 2006 20:04:44 GMT
APR's versioning guidelines are an awfully good practice, in my  


On Jan 15, 2006, at 10:42 AM, Alan D. Cabrera wrote:

> 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
> Regards,
> Alan

View raw message