geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From lichtner <licht...@bway.net>
Subject Re: Release and Version Philosophy [Discussion]
Date Sun, 15 Jan 2006 05:42:18 GMT

To me the only important requirements in release numbers are that they
should tell the user:

1. Whether the release is backward compatible.

2. Whether it's a stable build vs. unstable.

I would rather not to have to learn the various meanings of digits 1-N. It
seems like it would make it more transparent, but actually it makes it
less transparent because people need to think (!).

As far as patching goes, there will be people who want bug fix 5 but not
6,7,8 because they think that any change other than they one they want will
cause them to stay past five o'clock, but I think that those are the kind of
the people that must be made to pay for commercial support.

On Sun, 15 Jan 2006, Matt Hogstrom wrote:

> I've seen several posts about the upcoming 1.0.x release and 1.1 and 2.0 etc.
> lately and I think its great that we're having these discussions.
>
> I'd like to use this thread to aggregate people's thoughts about this topic in a
> single thread for reference and clarification as we make forward progress.  So
> I'd like to clarify some terminology (at least post what the terms mean to me)
> so we can make some meaningful plans for our various efforts going forward.
>
> This is a strawman so don't get too revved up.  I think we need to balance
> between structure and fluidity and I'm not sure exactly how to do that; input
> welcome.
>
> First, I see there is a structure for versioning like:
>
> v.r.m[.f] where:
>
> v = Version
> r = Release
> m = modification
> f = fix (optional)
>
> Version
> -------
> - Represents a significant set of improvements in Geronimo and a definite
> milestone for our users.
> - New features are introduced that may break compatibility and require users to
> have to modify their existing applications that ran on previous Versions.
> (Although we should strive to not force them to change immediately but rather
> provide something like a V-1 or -2 compatibility story.  -2 Would be excellent
> but that might be too optimistic given the rate of change.
> - Things like JEE 5 would be found in a version change.
> - Goes through a formal Release Candidate process for user feedback and has
> broad coverage in terms of announcement.  (Not just the Dev List)
> - Release Candidates look something like Geronimo-2.0-RC1/2/3 etc.
>
> Release
> -------
> - Can include significant new features / improvements.
> - Should not break existing applications (lot's of traffic from users saying
> something worked on M5 but doesn't on 1.0)
> - Includes bug fixes and the like.
> - It would be hard to justify moving to JEE 5 based on a release change.
> - Has broad announcement
> - Does not go through formal Release Candidate Process but does make interim
> release attempts based on a dated binary release (ala Geronimo-jetty-1.1-rc20060315)
>
> Modification
> ------------
> - Incremental release that builds on the goals of the V.R its based on.
> - Can include new features
> - Cannot disrupt existing application deployments
> - Includes multiple bug fixes
>
> Fix
> ---
> - Focused release that addresses a specific critical bug.
> - We're no where near this now but it would be nice to release specific bug
> fixes and not whole server releases.
> - An example of this would be something like a fix to the recent problem Jetty
> uncovered related to security.  A fix in this context would be a simple
> packaging change to get the new Jetty Jar into the build and wouldn't require a
> whole new server to be spun off.
>
> Thoughts?
>

Mime
View raw message