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 progr
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 tr
Matt Hogstrom wrote:
> First, I see there is a structure for versioning like:
>
> v.r.m[.f] where:
>
> v = Version
> r = Release
> m = modification
> f = fix (optional)
Another minor point - these names are a bit unwieldy and it is
difficult to say:
1.0 is the version of a Version release.
Matt,
good initiative!
I would like to see the philosophy include a bit of process about how
a version is create.
For example a believe a fix release should definitely be created by
the application of a few carefully QA'd patches to an existing released
branch of the code.
More over, I would l
Matt Hogstrom wrote, On 1/14/2006 9:02 PM:
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 referenc
APR's versioning guidelines are an awfully good practice, in my
experience.
http://apr.apache.org/versioning.html
-Brian
On Jan 15, 2006, at 10:42 AM, Alan D. Cabrera wrote:
Matt Hogstrom wrote, On 1/14/2006 9:02 PM:
I've seen several posts about the upcoming 1.0.x release and 1.1
and 2.0
APR's guidelines look very reasonable to me. Adopting them (perhaps
with a few minor tweaks or clarifications) would have the added benefit
of aligning Geronimo with an existing Apache standard/practice, which I think end users will certainly appreciate.
Best wishes,
Paul
On 1/15/06, Brian McCal
