geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sachin Patel <>
Subject Re: Thoughts about what a release is
Date Thu, 15 Jun 2006 13:53:44 GMT
I think it would make life more difficult managing so many versions  
and the compatibility between those version, however I think this  
would be beneifical for updating the server at a more granulized level.

Another approach is to break out the server into components (multiple  
modules making up a component identified by a groupId) and each group  
Id could have its own version.

On Jun 15, 2006, at 12:34 AM, Matt Hogstrom wrote:

> 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 <> 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.


View raw message