I'm also -1 on that particular point. I think that dev should happen on trunk always, and backporting is done on a case by case basis. It also looks more reasonable - develop on trunk, not on a released branch. But this might be just semantics ...
Shai On Mon, Apr 26, 2010 at 4:07 PM, Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > > > This is a vote for the proposal discussed on the 'Proposal about > > Version API "relaxation"' thread. > > > > The vote is to open up a separate parallel line of development, called > > unstable (on trunk), where non-back-compatible changes, slated for the > > next major release, may be safely developed. > > > > But it's not a free for all: the back compat break must still be > > carefully tracked in detail (maybe in CHANGES, maybe in a separate > > more detailed "guide" -- tbd), including migration instructions, so > > that this becomes the "migration guide" on how users can move to the > > new major release. If there are changes that break the index, we will > > try very hard to create an index migration tool. > > > > The stable line of development (on a branch) will be like trunk is > > today -- most dev happens on it, it's released more often (as minor > > releases and possible also .Z bugfix releases), it tries hard to > > maintain back compat. > > > > Changes that go into stable need to be merged forwards to unstable -- > > this may happen commit by commit, or be periodically swept, or some > > combination (like flex) -- we can hash out this logistical detail out > > with time. > > I am happy with "trunk" being the latest and greatest and the new branch > (e.g. called "lusolr_31"), but I am -1 on the whole proposal, because (same > argument as rmuir): > > Instead trunk (unstable) should have all the latest features, and > appropriate things merged back to the stable branch. This gives the added > benefit of not needing to freeze development for long periods of time while > releases are happening, etc. > > Uwe > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
