[kepler-dev] Code Freeze and Release Branch Information

[Chad Berkley]

Hey Christopher,

See my responses below:

Christopher Brooks wrote:
> 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.

It does look a bit cluttered, but I think it's necessary to allow 
individual module upgrades in the future.  For instance, the next 
release of kepler might only have changes to core and common.  Those 
modules would get revved but the others wouldn't.  The build system 
relies on the name of the module to keep track of versioning for each 
module.

> 
> 
> * 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.

Yeah, I was going to ask you about that.  I'll rev it to whatever the 
version of ptII we end using is.  That having been said, the version 
number in the directory is the version of the kepler module that 
contains ptolemy, not of ptolemy itself (obviously), but I agree with 
you that it is confusing.

> 
> 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

no, they don't.

> 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?

I'll just make sure the name of the ptolemy module matches whatever the 
shipped version of ptII is.


> 
> 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.

I'm not really up for changing that at this point.  Since anyone that's 
downloading this via kepler is getting it to use kepler (we no longer 
allow one to run standard vergil from kepler), I don't think it's that 
big of a deal.

> 
> * 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 ...

Yep, I was going to ask you about that too.  I'll change it.

Since we're now just going to work from the head and not the branch, 
I'll make these changes when we actually do branch.  Probably when a 
beta or RC is ready.

thanks for your input.

chad


> 
> 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
>