Jim Hurley wrote:
On Jul 18, 2007, at 10:24 AM, Mark Brouwer wrote:
Jim Hurley wrote:
:
To segment these into more historical versions (versus
what we're going to create in the River project), I thought
it might be better to preface these with "JTSK_" (for example,
JTSK_1.0, JTSK_1.1). Let me know if someone has a better
idea.
The problem is indeed that *if* we are going to create multiple
deliverables for River we are a bit stuck with the fact we have one
project in JIRA and JIRA has no notion of subprojects. As version
numbers are tied to a project we have a problem, solving this with
prefixing is kind of ugly as are components, etc. and in that case I
would favor to ask for multiple projects we can group, such as Avalon,
Geronimo, etc. see
https://issues.apache.org/jira/secure/BrowseProjects.jspa .
Nevertheless I'm not that much in favor of prefixing the version number
at this point with JTSK_ as we have no clear picture about what the
deliverables will be. And as version numbers can be renamed like
everything else in JIRA with great ease I think it is just fine to stick
with what is in Bugtraq and change when we have that picture and it
turns out to be a problem.
I understand your point -- but these aren't version numbers for
*this* project, they are historical version numbers for another
release. If we just put them in as "1.0, etc", I think it will be hard
But they are for exactly the same codebase, same beast. A codebase that
is referred to in a lot of worldwide documentation based on the JTSK
version numbering. I could argue that it would have been better in the
past if there was a clearer separation between the version numbering for
the specs versus the JTSK implementation but I'll refrain from that.
for people to understand what the version numbers that this project
has delivered (versus, version numbers present just so that we
can track when a bug/rfe had been submitted against years ago).
That's the only reason I wanted to preface the historical starter kit
version numbers.
This also tangentially raises the question on what we want our
first version number (that River will deliver) to be, so that we can
assign bugs to be fixed in that version. I know this also won't be
warmly received, but for now, I'll throw out "AR1" (Apache River 1).
The way I look to it is that River is the continuation of the JTSK
as developed by Sun and therefore I would expect a logical increase of
version number just because of the fact that to many the specs are
referred to as Jini 2 and went hand in hand with the implementation. If
it turns out that from the JTSK new beasts roll into the world I think
we can start with some fresh version numbering, but that is not the case
yet.
As a party that builds upon the Jini Platform/core/... I want to keep
something that I can refer to for compatibility and seems a logical
evolution. Of course if some spec/platform was separated from the final
deliverable the problem would be much less. But I don't believe we
should start with a version 1. I would say that if the first release is
an almost literal copy of JTSK 2.1 I would still go for 2.2 and when the
real work starts we head for 3.
Otherwise I would suggest to go for 2007.1 (2007.2, 2008.1, 2009.1) (I
know John McClain will love me for that :-), also a nice indication they
can expect a release this year.
Still this doesn't solve the problem I face with building on top of Jini
where I need something to say as Seven/Service/Product is compliant with
Jini version x.y
--
Mark
