I'm +0, mainly on terminology. I object to using the labels stable
and unstable for the names the branches. Simply call them what they
are, trunk and branch_3_1 (or whatever), and let quality judgement be
made elsewhere.
Erik
On Apr 29, 2010, at 6:09 AM, Michael McCandless wrote:
Reminder -- it's almost been 3 days for this vote -- anyone else want
to vote? I count these binding votes so far:
Robert +1
Shai +1
Uwe +1
Michael +1
Grant +0.9
Doron +1
Hoss +0
me +1
Mike
On Mon, Apr 26, 2010 at 11:59 AM, Michael McCandless
<[email protected]> wrote:
This is a vote for the proposal discussed on the 'Proposal about
Version API "relaxation"' thread. This thread replaces the first
VOTE 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 get
non-back-compat-breaking changes, and will be released more often (as
minor releases and possible also .Z bugfix releases).
Changes will go into unstable first and then be back ported to the
stable branch on a case by case basis as long as they don't break
back-compat. 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.
This is a procedural vote -- we need a majority of the Solr/Lucene
committers for this to pass.
Please vote!
My vote is +1.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
