[kepler-dev] Code Freeze and Release Branch Information

[Chad Berkley]

Thanks for asking about the schedule.  I meant to send an email with the 
revised dates out.  Since the code freeze was pushed a week, I pushed 
all the other dates 1 week as well.  Here's the new (tentative) schedule:

2/8: Code Freeze
2/8-2/12 Bug fix week
2/15-2/19 Testing/documentation week
2/19 Beta 1 (branch)
2/22-2/26 final documentation
3/1: RC1
3/1-3/5: test RC1
3/8: 2.0 release

chad

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