[kepler-dev] Code Freeze and Release Branch Information

Chad Berkley berkley at nceas.ucsb.edu
Mon Feb 8 14:43:24 PST 2010


Hi again,

We've had a slight change of plans with respect to how to work with the 
release code.  Instead of using a branch for this initial alpha phase of 
the release, we've decided to leave development on the trunk for now. 
We just ask that any development to the following modules be limited to 
documented bug fixes only (i.e. no new features):

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

I'll be monitoring the check-ins on these modules and if I see any new 
features, I'll ask you to move them to another module, where the feature 
can then be merged after the release.

If you have any questions, feel free to reply to this email.  Sorry for 
the confusion.

thanks,
chad


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


More information about the Kepler-dev mailing list