Craig L Russell wrote:
On Sep 25, 2007, at 1:01 PM, Dan Creswell wrote:
John McClain - Sun Microsystems, Inc. wrote:
Mark Brouwer wrote:
Finally, around version -- some have expressed a desire to follow
the version numbering of the starter kit (to align with those releases
and communicate that this isn't a 0.1 release or the like). Thus, the
last Starter Kit release was "v2.1" so this could be (v.2.1.1,
v2.2, or
v.3.0). I don't really have a personal preference on this one at all,
and am very interested in what your opinion is here.
v2.1.1
[snip]
I assume at some point before we exit incubation the need to move from
the com.sun.jini package name space will make us want to bump the
version number to at least 2.2, if not 3.0.
So this really matters at the point where we remove the com.sun.jini
packages entirely (we were talking about a "temporary" compatibility
type thing as a possibility).
Regardless when the removal happens if we haven't bumped the release
number substantially by then I too would have thought we should bump it
at that point.
To avoid confusion, I'd recommend that when you change package names,
you make a Major Release.
3.0 sounds like a good number.
Although now is probably not the right moment to discuss this, but I
think that bumping to 3.0 while e.g. all the Jini specifications in
net.jini are the same is only adding to the confusion.
I consider this a consequence of the unlucky historical coupling of the
specification(s) versions and the implementation and other stuff (aka
the JTSK). As such I would like to have a version numbering discussion
in the context of specification versus incarnation.
It might be that I'm alone in this (if so I really like to hear) but to
me River doesn't represent the only 'Jini' out there and at least I have
the need for something more stable on the network edge than something
for which version numbers are increased by the River versioning scheme
and whether a package name is changing and in that context might
represent a major release.
--
Mark
