geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Thoughts about what a release is
Date Thu, 15 Jun 2006 04:34:20 GMT
Not sure if this is already captured.

What do folks think about leaving the modules as independent pieces with their own version
numbers 
and the geronimo_version is just the aggregate release to users?  I expect this would make
out life 
more difficult but I haven't found the single version number to rule all modules all that
easy either.

Also, it would be nice that if a module hadn't changed then it stays static and is a good
indicator 
of where the activity is.

Thoughts?

Hiram Chirino wrote:
> On 6/11/06, Alan D. Cabrera <list@toolazydogs.com> wrote:
>>
>>   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.
>>
> 
> +1.  This allows us to time box the bug fix releases.  If we can get
> into the groove of doing regular x.y.z releases (at  like 1 a month
> intervals), then I think that also reduces the pressure on needing to
> make the x.y releases perfect.  I think we sometimes delay our x.y
> releases because we are aiming for perfection.
> 
> The only problem with the above is that it does not solve the problem
> of being able to time box the x.y release.  The since dev branch of
> the x.y release could have multiple new features at different levels
> of completion it's hard to stabilize at any given time.  Do you guys
> consider this a problem?
> 
> I like Dain's suggestion of splitting up the modules.  In theory in
> progress work being done separately versioned project should not hold
> up the time boxed release of a Geronimo x.y. Geronimo would just
> release with the previous stable version.  In practice, even for
> independently versioned projects like ActiveMQ, Geronimo will hold up
> it's releases to get new releases from ActiveMQ. This is bad if you
> want to time box a release.
> 
> Another thought that might help Geronimo be able to stay on a time box
> release cycle is making more use of 'development' branches.  We could
> encourage develops to work on new features in development branches
> that get merged in once the feature is fully working.  The down side
> to this is that it may not be obvious to other developers what work is
> going on where.
> 
> Or perhaps we need to do a a combination of independent versioned
> modules where most of the work happens, and then having small
> development branches of the main Geronimo module that holds the
> integration code that enables the new features.  So then then
> development branches are used to do integration testing with in
> progress features and they are merged in to trunk once the feature is
> done and all integration testing is completed.
> 
> 

Mime
View raw message