lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: [VOTE] Open up a separate line for unstable Solr/Lucene development
Date Mon, 26 Apr 2010 13:07:07 GMT

> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message