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 01:14:57 GMT
Aaron Mulder wrote:
> 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. 

I agree with you here.  The nice thing about the policy that I outlined 
below is that we can safely time box patch releases.

As for what gets scheduled for what release, I think that it's not 
realistic to start by stacking a release w/ issues and hope that people 
will "show up" to get them done in the scheduled time frame; this only 
works if we are making shoes ;).  With that said, time boxing is what 
would work best with our unique body of developers. 

Working within the strict interpretation of releases that I outlined 
below, people would schedule themselves in with concrete commitments. 

Bugs would not get scheduled in until someone actually picked it up and 
started working on it.  At that time, the developer would mark what 
releases his changes would fix.

Features would not get scheduled in until someone actually commits to 
doing that feature.  The larger the feature, the stricter the 
requirements are for milestones.


Regards,
Alan

> On 6/11/06, Alan D. Cabrera <list@toolazydogs.com> 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
>>
>>
>>


Mime
View raw message