geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: Thoughts about what a release is
Date Thu, 15 Jun 2006 12:58:59 GMT
Seems like a nightmare to me -
1) By not updating all the modules with every release, aren't we going 
to have problems with different module levels using different external 
dependency levels, like Log4J, Howl, Xerces, Commons-*, ... which will 
cause runtime exceptions when multiple levels of the same JAR are on the 
same classpath?
2) We already have difficulties in keeping the dependency version 
numbers in sync across Geronimo, Specs, Devtools, Daytrader, OpenEJB and 
TranQL....  It would only get worse to manage if we had to keep track of 
18 Spec versions and 45 module versions!

What would it really buy us, besides more work and more complicated builds?


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