dev@glassfish.java.net

Re: right way to use version numbers for modules

From: Bill Shannon <bill.shannon_at_sun.com>
Date: Sun, 16 Mar 2008 15:15:56 -0700

Craig L Russell wrote:
> Hi Sahoo,
>
> I think that version numbers on modules should be globally consistent
> and posted to a wiki page so everyone knows what they are.
>
> It would be nice if the numbering scheme reflected some uniform
> criteria: modules being developed would always have a SNAPSHOT suffix.
> Modules with a new JSR would have a major (first number) bump from
> previous. Modules with a maintenance release would have a minor bump.
> Modules that had bug fix maintenance that was not part of a JCP
> maintenance review would have a third level bump.
>
> I'm not saying that the above should be adopted verbatim, but that
> someone in authority put their rules out and publicly encourage projects
> to adopt them. Bill? Eduardo?

I think it's better if the version numbering for modules associated
with JCP specs follows the numbering of the JCP spec. At the JCP spec
level, the choice of minor or minor version number is largely one of
perception - is it a big change or a little change? A full JSR might
introduce either kind of change, but a Maintenance Review for a JCP
spec will generally be a minor change.

I've been encouraging people to use the third level (micro, or dot-dot
number) for changes to the implementation without changes to the spec.
(And, as all spec leads should know, changes to a spec document to fix
typos and minor errors of that sort that do not change the API syntax
or semantics should be indicated by a revision level (e.g., "Rev B")
on the spec document itself, not by a dot-dot number.)

In general, I agree that better version number management is needed for
our GlassFish V3 modules. I have a sense as to what would be reasonable
during "steady state", but I'm not sure what the best approach is during
these very turbulent early days when things are just starting to come
together. I hope that we will soon get to the point that most developers
will not need to even "check out" most modules to do their work. I think
moving to Mercurial and introducing more structure to our workspaces and
integration procedures will help, and will provide the framework for better
management of module versions and dependencies.

I have a dream... :-)