[kepler-dev] Code Freeze and Release Branch Information

Tue Feb 9 17:29:26 PST 2010

Hey Chad,
Ok, I'm convinced that the directories need the version numbers.
If you could change the ptolemy-2.0 to ptolemy-8.0, then that
would cover us.  We could have it be ptolemy-8.0.beta and then
ptolemy-8.0.1, but this seems like busy work.

Currently, you are asking for bug fixes only on the modules.
Do you have target date for actually splitting the tree?

_Christopher

On 2/9/10 9:50 AM, Chad Berkley wrote:
> 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
>>

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