[kepler-dev] [Bug 5396] rename ptolemy-8.1.0 module for the kepler 2.2 release

[bugzilla-daemon at ecoinformatics.org]

http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5396

Christopher Brooks <cxh at eecs.berkeley.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cxh at eecs.berkeley.edu

--- Comment #3 from Christopher Brooks <cxh at eecs.berkeley.edu> 2011-05-06 09:46:35 PDT ---
The ptII development tree has a version number of 8.1.devel, see
ptII/ptolemy/kernel/attributes/VersionAttribute.java

Traditionally, after branching the ptII tree in preparation for
a release, I bump the version number of the trunk to X.1.devel
and the release branch is X.0.alpha.

The reasoning for the X.0.alpha -> X.0.beta -> X.0.1 sequence is lost
in the sands of time.  I remember I tried 
X.0.alpha -> X.0.beta -> X.0 and there were problems.  I don't 
remember what the problems were.  It will probably come to me
if I try it, or it could have been an artifact of installer software
that is no longer being used.

The reason to go with 8.0.2 instead of 8.0.1 is because 8.0.1
has already been released as the current Ptolemy II 8.0 release.

It is unfortunate that the module system has a technical limitation.
VersionAttribute.java is based on the JNLP versioning system which
allows for arbitrary lengths of version names.

Kepler-2.1 was presumably based on a version of the ptII tree
that was not cleaned.  Who knows what shipped?  The files were not
formatted, no checks were made of the licensing or whether there
were broken links.

The notion of using a different version number for the version of
ptII that is shipped with Kepler will work fine until there are problems.
Tcl/Tk had similar issues, where Tk had a lower version number
than Tcl, but required Tcl to run.  The confusion about the version
numbers consumed quite a bit of email list discussion.

Another issue is that ptII has its version number encoded in the
VersionAttribute.  If you have a module named ptolemy-2.0.0, then
the VersionAttribute cannot be set to 2.0, as Ptolemy II 2.0 was released
in 2002 with VersionAttribute set to 2.0.  A side issue is that 
the "ptolemy" module is misnamed.  The name of the product is Ptolemy II.
The svn module is ptII.  The ptolemy cvs repository is Ptolemy Classic,
which is a separate repository.  By rights, the Kepler "ptolemy" module
should be renamed to "ptII".  However, this is a detail and probably
not worth addressing.

If there are technical reasons that you can't ship a ptII version of 8.0.2,
then I'd be happy to clean the tree and create a version 8.1.alpha
branch from the ptII head.  It would take a two weeks to get a real
8.1.0 tree out.  I'm traveling next week.  I could clean the tree today
and get a 8.1.alpha branch out by the end of the weekend.

In summary, my primary concern is that Kepler not ship with a version
number of Ptolemy II that is the same as a version of Ptolemy II that
has already shipped.  This means that the Ptolemy II version number
should be greater than 8.0.1.

My secondary concern is that Kepler should not artificially bump the
Ptolemy II version number up.  We were thinking of shipping a Ptolemy II 8.1,
so discussing this is good.  Kepler *could* ship with a Ptolemy II 8.1
version number if I clean the tree and the VersionAttribute is set
to 8.1.

My tertiary concern is that I would prefer that Kepler ship with
cleaned Ptolemy code.  This requires a little coordination and planning.
I can usually clean a tree in a day.  This concern is actually the
one that really matters the most because an uncleaned Ptolemy II tree
likely has broken links and could have licensing issues.

-- 
Configure bugmail: http://bugzilla.ecoinformatics.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.