On Jul 18, 2007, at 10:50 AM, Mark Brouwer wrote:
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 .
I'm not proposing multiple deliverables at this time.
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, personally, don't understand why there would be contention here.
Irrespective of the fact that the initial River codebase is
predominantly
comprised of the Starter Kit codebase -- we're talking about how we
can identify the issues that were filed against the old starter kit
releases
(versus future releases produced by the River project). It seems logical
to me that you'd want to make it clear that these are pre-existing
bugs/rfes
that were originally filed against the starter kit releases (that
we're importing
into the project).
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.
I'm not looking to go there right now.
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.
I guess I was looking to temporarily call it (in JIRA) "AR1" to not have
to dive into the "what are we really going to call the release
(starter kit,
something else?) and what version number is it going to have (0.1, 1.0,
2.2, etc?)". We'll have time to address that - but I'd rather make some
progress now. You've said that Release names in JIRA can be easily
changed - so I'd like to just call it *something* generic and move on.
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
Any other opinions from committers and folks on the list?
thanks -Jim
