http://bugzilla.ecoinformatics.org/show_bug.cgi?id=5396
Christopher Brooks <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #3 from Christopher Brooks <[email protected]> 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. _______________________________________________ Kepler-dev mailing list [email protected] http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
