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 Thu, 15 Jun 2006 19:31:37 GMT
Sorry, Hiram.  I'm not following.  Can you explain in greater detail?


Regards,
Alan

Hiram Chirino wrote:
> Well, for one, you could do a release of geronimo at any time since
> should stay stable as long as it does not move to SNAPSHOT
> dependencies.
>
> Regards,
> Hiram
>
> On 6/15/06, Donald Woods <drw_web@yahoo.com> wrote:
>> 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?
>>
>>
>> -Donald
>>
>> 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 <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