A clarification - stable/unstable are not really related to the 'stability' of the branch, right? I mean both trunk and branch will be stable in the sense that tests pass and I can safely use either of them. We're not going to start checking in code which is in the middle of dev, does not compile, tests fail etc. Right? Or did I missunderstood the intention?
Shai On Sunday, April 25, 2010, Michael McCandless <luc...@mikemccandless.com> wrote: > OK, so forget that suggestion :) > > It sounds like the best way to manage the branches is trunk = unstable > (X.0 major release), and long lived branch for ongoing stable dev > (X.Y.0 minor releases), and possible bug fix branches off of that > (X.Y.Z), on demand if needed. > > But the intention here is not to abandon the stable branch as soon as > it's cut. I expect many changes/devs will work mostly on the stable > branch since that branch does [minor] releases much more often than > the unstable branch. > > Changes that go into stable need to be merged to unstable, maybe > periodically sweeped or maybe merged up by the original committer or > likely some combination (like flex). > > (And, yes we'll still use other branches for big new features that are > in active development). > > Mike > > On Sun, Apr 25, 2010 at 1:21 PM, Earwin Burrfoot <ear...@gmail.com> wrote: >>> And, it's not the committer's job to port each little commit to stable >>> over to the unstable branch. Instead, we periodically re-sync stable >>> --> unstable, like we did with the long-lived flex branch. >>> >>> So, then, little would change on how stable is developed, today. And >>> stable would still be the primary source line for development. >> >> -1 >> >> And now there's no place I can go for latest-and-greatest. Some >> features in stable, other features in unstable - do I have to merge >> locally if I need all of them? >> If we have some new flex-calibre developments, they warrant their own >> branch, as they are totally unusable whilst in the works. >> >> The shining point of unstable is not that you can shove some flexy >> stuff there. It's that you can tweak APIs without regard to backwards >> compat, and have generally cleaner codebase. >> >> >> -- >> Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) >> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 >> ICQ: 104465785 >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
