Of course - its all a matter of degree. Trunk is not going to be 'super'
unstable - of course it will have to compile. It's still going to be
mostly like the current trunk and of course pass tests. Stable will
just be *more* stable than trunk. We are only using the terms
relatively. Stable will have backwards compatibility and fewer large,
hairy changes. It will be more evolutionary while trunk will be more
revolutionary.
On 4/25/10 1:56 PM, Shai Erera wrote:
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
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
