OK let's cancel this vote. I'll change the proposal, to dev on trunk and port back to stable, and call a new vote.
Mike On Mon, Apr 26, 2010 at 11:51 AM, Shai Erera <ser...@gmail.com> wrote: > 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 >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
