[kepler-dev] Code Freeze and Release Branch Information

[Christopher Brooks]

Hi Chad,
Awesome!
Congrats on branching!

A few small issues:
* All the packages have 2.0 in the version name.
This is not necessarily wrong, but looks a little unusual.  I'm
more used to the idea that Kepler-2.0 would contain modules that
do not have version numbers.  I can see the advantage to this
so that we could have modules with different version numbers.

What we have now is:

actors-2.0                      job-2.0
apple-extensions-2.0            kepler-2.0
authentication-2.0              kepler-tasks-2.0
authentication-gui-2.0          loader-2.0
build-area                      module-manager-2.0
common-2.0                      module-manager-gui-2.0
component-library-2.0           opendap-2.0
configuration-manager-2.0       outreach-2.0
core-2.0                        ptolemy-2.0
data-handling-2.0               r-2.0
directors-2.0                   repository-2.0
ecogrid-2.0                     sms-2.0
event-state-2.0                 ssh-2.0
gui-2.0                         util-2.0

I just think the above looks a little cluttered.


* ptolemy II 2.0 was released years ago, so please rename the
ptolemy module to either ptolemy or ptolemy-8.0.beta or ptolemy-8.0.
There will be confusion if the current "ptolemy-2.0" is used.
I saw this happen with Tcl/Tk, where Tcl and Tk had different
version numbers and there was much confusion.  People would not
realize what version of Tcl or Tk they were using and a bunch of
the support effort was spent figuring out what was being run.

BTW - The final 8.0 release will likely be ptII8.0.1.  The next patch
will be ptII8.0.2 etc.

The above two issues bring up the point that we need to make a decision.
Do all the modules in the kepler-2.0 suite have to have -2.0 in
their names?  I say no, since kepler-2.0 uses versioned software with
other version numbers.  Most of the modules _could_ have -2.0 in their names.
As versions change, would we be updating?  For example, if Kepler-2.0.beta
shipped with PtII8.0.beta, would the file be ptolemy-8.0.beta.
Then, when Kepler-2.0.0 shipped with ptII8.0.1, would we change
this to ptolemy-8.0.1?

It might be instructive to look at how Eclipse uses versioning for their
jar files.  For example Eclipse has:
org.openarchitectureware.xtext.core_4.3.1.20090107-2000PRD.jar
4.3.1 is the version number of openArchitectureWare.
20090107 is the date the jar was built (sort of a build number).

I'm not advocating dates in the module names, but I am advocating
following the version numbering of the packages that are used by Kepler.

* I have a slight preference for renaming ptolemy to ptII.  The reason
is that the Ptolemy Project produces software and one such package is
Ptolemy II, which we call ptII.   Really, there is no software called
Ptolemy.  There was software called Ptolemy that we retroactively renamed
to Ptolemy Classic.  There is software called Ptolemy II.
However, I can live with ptolemy-8.0.1 in Kepler.

* It looks like you are checking out Ptolemy from the trunk:

[change-to] svn co -r head svn://source.eecs.berkeley.edu/chess/ptII/trunk /Users\
/cxh/src/kepler-2.0/ptolemy-2.0/src

Instead, please use the Ptolemy II beta branch:
svn co svn://source.eecs.berkeley.edu/chess/ptII/branches/rel-8-0-beta ...

Again, congrats on the branch!

_Christopher










On 2/8/10 1:41 PM, Chad Berkley wrote:
> Hi Kepler-dev,
>
> Just want to let everyone know that features for Kepler 2.0 should no
> longer be added to the repository. The repository has been branched for
> the 2.0 release here:
> https://code.kepler-project.org/code/kepler/branches/releases/release-branches/
>
>
> To checkout the branch, use the following commands:
>
> bash$ mkdir kepler-2.0
> bash$ cd kepler-2.0
> bash$ svn co
> https://code.kepler-project.org/code/kepler/branches/releases/release-branches/build-area-2.0
> build-area
> bash$ cd build-area
> bash$ ant change-to -Dsuite=kepler-2.0
> bash$ ant run
>
> All bug fixes for 2.0 should be committed to this branch. Any bug fix
> that also affects the trunk should also be committed there.
>
> As of right now, there are 38 bugs in bugzilla. If you want something to
> work on but don't know where to start, please let me know. Please report
> any new bugs as soon as you find them and make sure you target the bug
> to 2.0.0. Also, if you are working on a bug, please "accept" it as yours
> so we know you're working on it and don't duplicate work. If the status
> is still "new" it will probably get worked on by someone else even if
> you're currently assigned to it. That should not happen with bugs with a
> status of "assigned."
>
> Let me know if you have any questions. Happy bug fixing!
>
> thanks,
> chad
>
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev

-- 
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670