geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: Thoughts about what a release is
Date Mon, 12 Jun 2006 00:42:40 GMT
Matt Hogstrom wrote:
> *What constitutes a release?*
> Speaking from my IBM WebSphere days (just as a point of reference for 
> discussion and not specifically a recommendation) we generally 
> differentiated products based on Versions and Releases.  Versions were 
> significant new content and function which might be defined as a new 
> J2EE specification implementation, significant new function 
> (clustering improvements might fall in this category), etc.
>
> Releases were less dramatic and more incremental in nature.  They 
> could include performance improvements, new features that were not 
> disruptive to previous releases (such as improved CMP persistence 
> options, etc.) or perhaps even a JDK Version upgrade from 1.4 to 1.5 
> for instance. Releases could also include what we referred to as tech 
> previews.  These were items that we wanted people to have a chance to 
> start using but it wasn't fully baked yet.  However, we did not want 
> to wait a whole version release to put it in the hands of the users.
>
> So for notational usefulness.  We saw a version number break down like 
> v.r.m where V is the major version number, R was the release number 
> and M was a modification level.
>
> Modification levels could include new features of a limited nature as 
> described above.  One was simply aware of how it would impact the 
> users in terms of determining appropriateness.
>
> Thoughts?

I prefer the more conventional nomenclature of major, minor, and patch.  
The explain this I will grossly plagiarize what Noel Bergman posted on 
the James list.

  X.Y.z:  patch release - bug fixes
  X.y:    minor release - bug fixes and compatible enhancements
  x:      major release - major enhancements, and incompatible changes


I am very much against placing anything but patches in the .z releases.  
Let me explain why.  When we make a minor release we basically branch 
the X.y release for the purposes of  releasing patches.  Any changes to 
this branch, e.g. patches, must also be immediately applied to the 
trunk.  If we make any enhancements to this branch, we must also 
immediately apply the same enhancement to that branch.  This adds 
significant more risk that bug patching but more importantly when we 
fall into the trap of putting minor enhancements into a patch release, 
we remove the most serious impetus to getting the minor release done and 
out the door.

Let us make an honest assessment of ourselves based on past out 
behavior, we do not have the discipline that it takes to put only minor 
enhancements into a patch release.


Regards,
Alan



Mime
View raw message