geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Thoughts about what a release is
Date Mon, 12 Jun 2006 17:54:11 GMT
I am a bit torn here, because I agree with both of you depending on  
which code we are talking about.  Geronimo is a large project and I  
think we will be doing ourselves a disservice if we attempt to treat  
all of the code the same.  For example, I think Alan's comments apply  
best to the core transaction processing parts of geronimo, and I  
think think Aaron's comments apply best to non-critical parts of the  
server like the console and tooling.  I would be upset if someone  
tried to add a new feature to the core server in a micro release, but  
if they say added a new command to the cli or a new portlet, I  
wouldn't be upset at all.

Can we find a compromise where critical code moves more  
conservatively and non-critical code gets more liberal rules?  If  
not, I think we should start talking about how to divide up the code  
base into independently versioned released components.  This will  
take a lot of effort in architecture and organization in our team.   
I'd rather not do it at this time, but maybe the time has come sooner  
that I wanted.

-dain

On Jun 11, 2006, at 6:14 PM, Alan D. Cabrera wrote:

> 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