On Dec 19, 2010, at 15:15 , Luis Lavena wrote: > I've merged the code for one of the pull/feature contributions a few > days ago, but search couldn't find the concrete logic against 1.4 and > 1.9 branches. > > Is the code in 1.4 the one that is going to be released next? Shall I > merge first there the new features and then merge to master? > > A good hint on the workflow will be great, thank you.
Eric is in the rainforest and JB is MIA... so I'll take a stab at it and if I'm wrong, I'm sure I'll hear about it later :) The code in 1.4 is intended to be released next, and it is currently in a passing state (but... my git-fu is poor). As far as workflow goes, all development should go on master and then be merged to the 1.4 branch once sanctioned. and really... ALL master code should be merged to 1.4--we shouldn't be that far ahead of ourselves. I don't think the 1.9 branch is meant to stay, just to manage the chaos currently going on with ruby-core's rubygems vs ours. Once everything is reconciled, I think that branch should go away and all changes made to ruby-core's rubygems should be immediately rolled out without reservation. Otherwise it gets to be too much. Don't bother merging to it. We should be pushing from our release branch to ruby-core's svn as-is. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
