geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Thoughts about what a release is
Date Mon, 12 Jun 2006 00:55:37 GMT
I'd feel a lot better about tight restrictions on 1.1.1 if we really
made 1.2 a "minor release" and put all the stuff on the plate for 1.2
into 2.0.  But so long as 1.2 is a major release, then 1.1.1 needs
more than hot fixes.  On a related point, I'm not sure we want
multiple big version releases per year.


On 6/11/06, Alan D. Cabrera <> wrote:
> 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

View raw message