Re: Thoughts about what a release is

[Donald Woods]

Aren't the configuration plans (CARs) already an implementation of that idea?

-Donald

Sachin Patel wrote:

Matt, are you suggesting something like we group a Config/Plugin and its module dependencies into a separate subproject that will be built with its own version number, like say a geronimo-axis subproject that includes the axis and axis-deployer modules into a single config/CAR that could be used to add everything needed for Axis to a server assembly? If so, then that makes more sense than having independent version numbers for every module and config we build.... Also, wouldn't this idea require that we update all of the modules and configs as part of 1.2 to not use specific dependency versions?

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.

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

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.

Not sure if this is already captured.





Thoughts?

Hiram Chirino wrote:

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.

On 6/11/06, Alan D. Cabrera <[EMAIL PROTECTED]> 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



Let me explain why.  When we make a minor release we basically  branch

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,

out the door.

I am very much against placing anything but patches in the .z releases. the X.y release for the purposes of releasing patches. Any changes to we remove the most serious impetus to getting the minor release done and

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

-sachin

smime.p7s
Description: S/MIME Cryptographic Signature