On Fri, Feb 24, 2012 at 12:46:28AM +0100, Francisco Vila wrote: > 2012/2/17 Graham Percival <gra...@percival-music.ca>: > > - nobody touches the release/unstable branch, than translators, > > who may merge with that if they want to and don't break > > anything.
oops, that should have read "other than translators". > I am going to merge lilypond/translation into release/unstable, but I > don't want to lose those translations for master and 2.17. I could > either A) also merge lilypond/translation into staging as usual, or B) > wait for anyone else to merge release/unstable into staging (I see > that it has been done already once). > > Are those options correct? Which is best? Since there are Critical issues, the current release/unstable is not a candidate for release. In this case, just merge into staging as normal. When I screw up git branches with releases -- which is not a rare event -- I generally end up deleting the current release/unstable and just make another one. I could try to remember to merge release/unstable into staging before deleting it, but no promises. Granted, as long as you have lilypond/translation, we won't lose any work. This doesn't really answer the question of what to do when there's an actual viable release candidate... although at the moment I can't think of any reason *not* to merge into staging provided that there's no conflicts. Such conflicts would only arise if there's a serious divergence between release/unstable and master, but I refuse to maintain a long-term distinct release branch for precisely that reason. - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
