OK this vote has passed! I think we now need to, roughly:
* Cut a stable branch off of trunk back before flex landed. Does anyone have any suggestions of which rev...? * Trunk then becomes 4.0 dev, so, we can selectively remove back compat layers (eg flex's) * Back-port to stable any "stable" fixes, committed after flex landed. Mike On Thu, Apr 29, 2010 at 8:40 AM, Mark Miller <[email protected]> wrote: > +1 - hopefully upgrading over major releases doesn't become a nightmare > though. > > On 4/29/10 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] >> > > > -- > - Mark > > http://www.lucidimagination.com > > --------------------------------------------------------------------- > 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]
