geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino" <hi...@hiramchirino.com>
Subject Re: Thoughts about what a release is
Date Thu, 15 Jun 2006 13:39:40 GMT
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.
> >>
> >>
> >
> >
>
>
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Mime
View raw message