You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Michael McCandless <lu...@mikemccandless.com> on 2010/04/26 17:59:56 UTC
[VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael Busch <bu...@gmail.com>.
+1
Michael
On 4/26/10 8:59 AM, Michael McCandless 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Shai Erera <se...@gmail.com>.
+1
Shai
On Mon, Apr 26, 2010 at 7:06 PM, Robert Muir <rc...@gmail.com> wrote:
> +1
>
>
> On Mon, Apr 26, 2010 at 11:59 AM, Michael McCandless <
> lucene@mikemccandless.com> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
>
> --
> Robert Muir
> rcmuir@gmail.com
>
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Robert Muir <rc...@gmail.com>.
+1
On Mon, Apr 26, 2010 at 11:59 AM, Michael McCandless <
lucene@mikemccandless.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Robert Muir
rcmuir@gmail.com
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Earwin Burrfoot <ea...@gmail.com>.
I believe Uwe tagged trunk just before flex landing.
On Fri, Apr 30, 2010 at 23:00, Shai Erera <se...@gmail.com> wrote:
> I would take the last rev just before the first rev when flex landed,
> so that in includes as much as possible. I don't know though which rev
> is it and whether it was before/after the lucene/solr merge.
>
> Shai
>
> On Friday, April 30, 2010, Chris Hostetter <ho...@fucit.org> wrote:
>>
>> : * Cut a stable branch off of trunk back before flex landed. Does
>> : anyone have any suggestions of which rev...?
>>
>> shouldn't this just be the same as the lucene/java/branches/lucene_3_0
>> branch that already exists? ... but with solr merged in?
>>
>>
>>
>> -Hoss
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Phone: +7 (495) 683-567-4
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Grant Ingersoll <gs...@apache.org>.
On May 4, 2010, at 1:46 AM, Chris Hostetter wrote:
>
> : +1 on calling them 3x and trunk. Then as 3.1, 3.2 etc are released, we
> : create appropriate branches + tags, like today.
> :
> : IMO, the words stable/unstable add nothing but confusion.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Chris Hostetter <ho...@fucit.org>.
: +1 on calling them 3x and trunk. Then as 3.1, 3.2 etc are released, we
: create appropriate branches + tags, like today.
:
: IMO, the words stable/unstable add nothing but confusion.
+1
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Shai Erera <se...@gmail.com>.
+1 on calling them 3x and trunk. Then as 3.1, 3.2 etc are released, we
create appropriate branches + tags, like today.
IMO, the words stable/unstable add nothing but confusion.
Shai
On Tue, May 4, 2010 at 3:57 AM, Uwe Schindler <uw...@thetaphi.de> wrote:
> I will start tomorrow morning MET to create the branch and merge CTA and
> some other issues made by me - hopefully we have a good name until this
> time. Renaming after the branching is a bad idea, as this makes merge logs
> hard to understand. I will also copy the Hudson configs after creating the
> branch.
>
> After that I am on vacation until next Wednesday, this is why I want to do
> it tomorrow morning!
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Michael McCandless [mailto:lucene@mikemccandless.com]
> > Sent: Tuesday, May 04, 2010 1:32 AM
> > To: dev@lucene.apache.org
> > Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
> > Solr/Lucene development
> >
> > I think maint sends the wrong message, ie, dev should be active (not
> > just maintenance) on the stable branch.
> >
> > We could just do 3x (ie drop "stable_" from it)?
> >
> > Mike
> >
> > On Mon, May 3, 2010 at 6:25 PM, Marvin Humphrey
> > <ma...@rectangular.com> wrote:
> > > On Mon, May 03, 2010 at 06:21:08PM -0400, Erik Hatcher wrote:
> > >> Can we please not use the word "stable"/"unstable" for these things?
> > >
> > > One possibility: "maint_31", "maint_32", etc.
> > >
> > > Marvin Humphrey
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
RE: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Uwe Schindler <uw...@thetaphi.de>.
I will start tomorrow morning MET to create the branch and merge CTA and some other issues made by me - hopefully we have a good name until this time. Renaming after the branching is a bad idea, as this makes merge logs hard to understand. I will also copy the Hudson configs after creating the branch.
After that I am on vacation until next Wednesday, this is why I want to do it tomorrow morning!
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Tuesday, May 04, 2010 1:32 AM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
> Solr/Lucene development
>
> I think maint sends the wrong message, ie, dev should be active (not
> just maintenance) on the stable branch.
>
> We could just do 3x (ie drop "stable_" from it)?
>
> Mike
>
> On Mon, May 3, 2010 at 6:25 PM, Marvin Humphrey
> <ma...@rectangular.com> wrote:
> > On Mon, May 03, 2010 at 06:21:08PM -0400, Erik Hatcher wrote:
> >> Can we please not use the word "stable"/"unstable" for these things?
> >
> > One possibility: "maint_31", "maint_32", etc.
> >
> > Marvin Humphrey
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Mark Miller <ma...@gmail.com>.
I still think stable/unstable makes perfect sense - and its used plenty
in this manner elsewhere.
I think it's already widely understood that unstable does not mean
"buggy and prone to crash" in this context. It means the code is rapidly
changing - possibly in fundamental ways. Some think that it may warn
users off trunk - but if it does, thats rightly so - when huge changes
like Flex hit unstable, its bound to have bugs. Its bound to have
problems that will be fixed over time. By the time it makes it to
stable, most of the issues will be worked out, and that will be the time
that most users should be getting on board.
The stable branch's changes will be much less drastic, or "hairy". The
majority of the code will be code that has been out for a while and
proven, or new features that are built on that proven code. As the rules
of back compat are lifted, trunk is likely to become even more unstable
than it has been in the past - and deserving the title IMO.
stable: resistant to change of position or condition
unstable: lacking stability or fixity or firmness
On 05/03/2010 07:32 PM, Michael McCandless wrote:
> I think maint sends the wrong message, ie, dev should be active (not
> just maintenance) on the stable branch.
>
> We could just do 3x (ie drop "stable_" from it)?
>
> Mike
>
> On Mon, May 3, 2010 at 6:25 PM, Marvin Humphrey<ma...@rectangular.com> wrote:
>
>> On Mon, May 03, 2010 at 06:21:08PM -0400, Erik Hatcher wrote:
>>
>>> Can we please not use the word "stable"/"unstable" for these things?
>>>
>> One possibility: "maint_31", "maint_32", etc.
>>
>> Marvin Humphrey
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Marvin Humphrey <ma...@rectangular.com>.
> > One possibility: "maint_31", "maint_32", etc.
> I think maint sends the wrong message, ie, dev should be active (not
> just maintenance) on the stable branch.
>
> We could just do 3x (ie drop "stable_" from it)?
If the intent is a single branch named "3x" rather than multiple branches
named e.g. "31", "32"... then here's my non-binding +1.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
I think maint sends the wrong message, ie, dev should be active (not
just maintenance) on the stable branch.
We could just do 3x (ie drop "stable_" from it)?
Mike
On Mon, May 3, 2010 at 6:25 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> On Mon, May 03, 2010 at 06:21:08PM -0400, Erik Hatcher wrote:
>> Can we please not use the word "stable"/"unstable" for these things?
>
> One possibility: "maint_31", "maint_32", etc.
>
> Marvin Humphrey
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Mon, May 03, 2010 at 06:21:08PM -0400, Erik Hatcher wrote:
> Can we please not use the word "stable"/"unstable" for these things?
One possibility: "maint_31", "maint_32", etc.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Erik Hatcher <er...@gmail.com>.
Can we please not use the word "stable"/"unstable" for these things?
Thanks,
Erik
On May 3, 2010, at 6:01 PM, Uwe Schindler wrote:
> stable_31
>
> after that stable_32 (if ever comes before 4.0)
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> Sent: Monday, May 03, 2010 11:57 PM
>> To: dev@lucene.apache.org
>> Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
>> Solr/Lucene development
>>
>> Yeah, I think so?
>>
>> How about naming it stable_3x?
>>
>> Mike
>>
>> On Mon, May 3, 2010 at 5:44 PM, Uwe Schindler <uw...@thetaphi.de>
>> wrote:
>>> So you mean the Tag as branch?
>>>
>>> -----
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: uwe@thetaphi.de
>>>
>>>
>>>> -----Original Message-----
>>>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>>>> Sent: Monday, May 03, 2010 11:40 PM
>>>> To: dev@lucene.apache.org
>>>> Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
>>>> Solr/Lucene development
>>>>
>>>> How about we cut the stable branch from just before flex landed?
>>>>
>>>> Then we can revert any changes from stable, and port back any
>> changes
>>>> from unstable/trunk, over time.
>>>>
>>>> Mike
>>>>
>>>> On Fri, Apr 30, 2010 at 3:18 PM, Steven A Rowe <sa...@syr.edu>
>> wrote:
>>>>> March 23: Create new Lu-Solr development folder
>>>>> <http://svn.apache.org/viewvc?view=revision&revision=926572>
>>>>>
>>>>> April 6: LUCENE-2370: Reintegrate flex_1458 branch into trunk
>>>> (revision 931101)
>>>>> <http://svn.apache.org/viewvc?view=revision&revision=931278>
>>>>>
>>>>> On 04/30/2010 at 3:00 PM, Shai Erera wrote:
>>>>>> I would take the last rev just before the first rev when flex
>>>> landed,
>>>>>> so that in includes as much as possible. I don't know though
>> which
>>>> rev
>>>>>> is it and whether it was before/after the lucene/solr merge.
>>>>>>
>>>>>> Shai
>>>>>>
>>>>>> On Friday, April 30, 2010, Chris Hostetter
>>>> <ho...@fucit.org>
>>>>>> wrote:
>>>>>>>
>>>>>>>> * Cut a stable branch off of trunk back before flex landed.
>>>> Does
>>>>>>>> anyone have any suggestions of which rev...?
>>>>>>>
>>>>>>> shouldn't this just be the same as the
>>>> lucene/java/branches/lucene_3_0
>>>>>>> branch that already exists? ... but with solr merged in?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Hoss
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------
>> ---
>>>> ---
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------------
>> ---
>>>> - To
>>>>>> unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>>>> additional
>>>>>> commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>> ---
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>
>>>>
>>>> --------------------------------------------------------------------
>> -
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi Mike,
I think you are right stable_3x is better, once we release 31, we create another branch 31 and continue with 3x until 32 comes out.
I think I will start tomorrow morning to create the branch and merge CharTermAtt and StandardAnalyzer refactoring?
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Uwe Schindler [mailto:uwe@thetaphi.de]
> Sent: Tuesday, May 04, 2010 12:02 AM
> To: dev@lucene.apache.org
> Subject: RE: [VOTE] Take 2: Open up a separate line for unstable
> Solr/Lucene development
>
> stable_31
>
> after that stable_32 (if ever comes before 4.0)
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
> > -----Original Message-----
> > From: Michael McCandless [mailto:lucene@mikemccandless.com]
> > Sent: Monday, May 03, 2010 11:57 PM
> > To: dev@lucene.apache.org
> > Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
> > Solr/Lucene development
> >
> > Yeah, I think so?
> >
> > How about naming it stable_3x?
> >
> > Mike
> >
> > On Mon, May 3, 2010 at 5:44 PM, Uwe Schindler <uw...@thetaphi.de>
> wrote:
> > > So you mean the Tag as branch?
> > >
> > > -----
> > > Uwe Schindler
> > > H.-H.-Meier-Allee 63, D-28213 Bremen
> > > http://www.thetaphi.de
> > > eMail: uwe@thetaphi.de
> > >
> > >
> > >> -----Original Message-----
> > >> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> > >> Sent: Monday, May 03, 2010 11:40 PM
> > >> To: dev@lucene.apache.org
> > >> Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
> > >> Solr/Lucene development
> > >>
> > >> How about we cut the stable branch from just before flex landed?
> > >>
> > >> Then we can revert any changes from stable, and port back any
> > changes
> > >> from unstable/trunk, over time.
> > >>
> > >> Mike
> > >>
> > >> On Fri, Apr 30, 2010 at 3:18 PM, Steven A Rowe <sa...@syr.edu>
> > wrote:
> > >> > March 23: Create new Lu-Solr development folder
> > >> > <http://svn.apache.org/viewvc?view=revision&revision=926572>
> > >> >
> > >> > April 6: LUCENE-2370: Reintegrate flex_1458 branch into trunk
> > >> (revision 931101)
> > >> > <http://svn.apache.org/viewvc?view=revision&revision=931278>
> > >> >
> > >> > On 04/30/2010 at 3:00 PM, Shai Erera wrote:
> > >> >> I would take the last rev just before the first rev when flex
> > >> landed,
> > >> >> so that in includes as much as possible. I don't know though
> > which
> > >> rev
> > >> >> is it and whether it was before/after the lucene/solr merge.
> > >> >>
> > >> >> Shai
> > >> >>
> > >> >> On Friday, April 30, 2010, Chris Hostetter
> > >> <ho...@fucit.org>
> > >> >> wrote:
> > >> >> >
> > >> >> > > * Cut a stable branch off of trunk back before flex
> landed.
> > >> Does
> > >> >> > > anyone have any suggestions of which rev...?
> > >> >> >
> > >> >> > shouldn't this just be the same as the
> > >> lucene/java/branches/lucene_3_0
> > >> >> > branch that already exists? ... but with solr merged in?
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > -Hoss
> > >> >> >
> > >> >> >
> > >> >> > -------------------------------------------------------------
> --
> > ---
> > >> ---
> > >> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > >> >> >
> > >> >> >
> > >> >>
> > >> >> ---------------------------------------------------------------
> --
> > ---
> > >> - To
> > >> >> unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > >> additional
> > >> >> commands, e-mail: dev-help@lucene.apache.org
> > >> >
> > >> >
> > >> >
> > >> > ----------------------------------------------------------------
> --
> > ---
> > >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > >> >
> > >> >
> > >>
> > >> ------------------------------------------------------------------
> --
> > -
> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Uwe Schindler <uw...@thetaphi.de>.
stable_31
after that stable_32 (if ever comes before 4.0)
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Monday, May 03, 2010 11:57 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
> Solr/Lucene development
>
> Yeah, I think so?
>
> How about naming it stable_3x?
>
> Mike
>
> On Mon, May 3, 2010 at 5:44 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> > So you mean the Tag as branch?
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> >
> >> -----Original Message-----
> >> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> >> Sent: Monday, May 03, 2010 11:40 PM
> >> To: dev@lucene.apache.org
> >> Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
> >> Solr/Lucene development
> >>
> >> How about we cut the stable branch from just before flex landed?
> >>
> >> Then we can revert any changes from stable, and port back any
> changes
> >> from unstable/trunk, over time.
> >>
> >> Mike
> >>
> >> On Fri, Apr 30, 2010 at 3:18 PM, Steven A Rowe <sa...@syr.edu>
> wrote:
> >> > March 23: Create new Lu-Solr development folder
> >> > <http://svn.apache.org/viewvc?view=revision&revision=926572>
> >> >
> >> > April 6: LUCENE-2370: Reintegrate flex_1458 branch into trunk
> >> (revision 931101)
> >> > <http://svn.apache.org/viewvc?view=revision&revision=931278>
> >> >
> >> > On 04/30/2010 at 3:00 PM, Shai Erera wrote:
> >> >> I would take the last rev just before the first rev when flex
> >> landed,
> >> >> so that in includes as much as possible. I don't know though
> which
> >> rev
> >> >> is it and whether it was before/after the lucene/solr merge.
> >> >>
> >> >> Shai
> >> >>
> >> >> On Friday, April 30, 2010, Chris Hostetter
> >> <ho...@fucit.org>
> >> >> wrote:
> >> >> >
> >> >> > > * Cut a stable branch off of trunk back before flex landed.
> >> Does
> >> >> > > anyone have any suggestions of which rev...?
> >> >> >
> >> >> > shouldn't this just be the same as the
> >> lucene/java/branches/lucene_3_0
> >> >> > branch that already exists? ... but with solr merged in?
> >> >> >
> >> >> >
> >> >> >
> >> >> > -Hoss
> >> >> >
> >> >> >
> >> >> > ---------------------------------------------------------------
> ---
> >> ---
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >> >
> >> >> >
> >> >>
> >> >> -----------------------------------------------------------------
> ---
> >> - To
> >> >> unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> >> additional
> >> >> commands, e-mail: dev-help@lucene.apache.org
> >> >
> >> >
> >> >
> >> > ------------------------------------------------------------------
> ---
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >
> >> >
> >>
> >> --------------------------------------------------------------------
> -
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
Yeah, I think so?
How about naming it stable_3x?
Mike
On Mon, May 3, 2010 at 5:44 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> So you mean the Tag as branch?
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> Sent: Monday, May 03, 2010 11:40 PM
>> To: dev@lucene.apache.org
>> Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
>> Solr/Lucene development
>>
>> How about we cut the stable branch from just before flex landed?
>>
>> Then we can revert any changes from stable, and port back any changes
>> from unstable/trunk, over time.
>>
>> Mike
>>
>> On Fri, Apr 30, 2010 at 3:18 PM, Steven A Rowe <sa...@syr.edu> wrote:
>> > March 23: Create new Lu-Solr development folder
>> > <http://svn.apache.org/viewvc?view=revision&revision=926572>
>> >
>> > April 6: LUCENE-2370: Reintegrate flex_1458 branch into trunk
>> (revision 931101)
>> > <http://svn.apache.org/viewvc?view=revision&revision=931278>
>> >
>> > On 04/30/2010 at 3:00 PM, Shai Erera wrote:
>> >> I would take the last rev just before the first rev when flex
>> landed,
>> >> so that in includes as much as possible. I don't know though which
>> rev
>> >> is it and whether it was before/after the lucene/solr merge.
>> >>
>> >> Shai
>> >>
>> >> On Friday, April 30, 2010, Chris Hostetter
>> <ho...@fucit.org>
>> >> wrote:
>> >> >
>> >> > > * Cut a stable branch off of trunk back before flex landed.
>> Does
>> >> > > anyone have any suggestions of which rev...?
>> >> >
>> >> > shouldn't this just be the same as the
>> lucene/java/branches/lucene_3_0
>> >> > branch that already exists? ... but with solr merged in?
>> >> >
>> >> >
>> >> >
>> >> > -Hoss
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------
>> ---
>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >
>> >> >
>> >>
>> >> --------------------------------------------------------------------
>> - To
>> >> unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>> additional
>> >> commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Uwe Schindler <uw...@thetaphi.de>.
So you mean the Tag as branch?
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Monday, May 03, 2010 11:40 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] Take 2: Open up a separate line for unstable
> Solr/Lucene development
>
> How about we cut the stable branch from just before flex landed?
>
> Then we can revert any changes from stable, and port back any changes
> from unstable/trunk, over time.
>
> Mike
>
> On Fri, Apr 30, 2010 at 3:18 PM, Steven A Rowe <sa...@syr.edu> wrote:
> > March 23: Create new Lu-Solr development folder
> > <http://svn.apache.org/viewvc?view=revision&revision=926572>
> >
> > April 6: LUCENE-2370: Reintegrate flex_1458 branch into trunk
> (revision 931101)
> > <http://svn.apache.org/viewvc?view=revision&revision=931278>
> >
> > On 04/30/2010 at 3:00 PM, Shai Erera wrote:
> >> I would take the last rev just before the first rev when flex
> landed,
> >> so that in includes as much as possible. I don't know though which
> rev
> >> is it and whether it was before/after the lucene/solr merge.
> >>
> >> Shai
> >>
> >> On Friday, April 30, 2010, Chris Hostetter
> <ho...@fucit.org>
> >> wrote:
> >> >
> >> > > * Cut a stable branch off of trunk back before flex landed.
> Does
> >> > > anyone have any suggestions of which rev...?
> >> >
> >> > shouldn't this just be the same as the
> lucene/java/branches/lucene_3_0
> >> > branch that already exists? ... but with solr merged in?
> >> >
> >> >
> >> >
> >> > -Hoss
> >> >
> >> >
> >> > ------------------------------------------------------------------
> ---
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >
> >> >
> >>
> >> --------------------------------------------------------------------
> - To
> >> unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> additional
> >> commands, e-mail: dev-help@lucene.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
How about we cut the stable branch from just before flex landed?
Then we can revert any changes from stable, and port back any changes
from unstable/trunk, over time.
Mike
On Fri, Apr 30, 2010 at 3:18 PM, Steven A Rowe <sa...@syr.edu> wrote:
> March 23: Create new Lu-Solr development folder
> <http://svn.apache.org/viewvc?view=revision&revision=926572>
>
> April 6: LUCENE-2370: Reintegrate flex_1458 branch into trunk (revision 931101)
> <http://svn.apache.org/viewvc?view=revision&revision=931278>
>
> On 04/30/2010 at 3:00 PM, Shai Erera wrote:
>> I would take the last rev just before the first rev when flex landed,
>> so that in includes as much as possible. I don't know though which rev
>> is it and whether it was before/after the lucene/solr merge.
>>
>> Shai
>>
>> On Friday, April 30, 2010, Chris Hostetter <ho...@fucit.org>
>> wrote:
>> >
>> > > * Cut a stable branch off of trunk back before flex landed. Does
>> > > anyone have any suggestions of which rev...?
>> >
>> > shouldn't this just be the same as the lucene/java/branches/lucene_3_0
>> > branch that already exists? ... but with solr merged in?
>> >
>> >
>> >
>> > -Hoss
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>>
>> --------------------------------------------------------------------- To
>> unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Steven A Rowe <sa...@syr.edu>.
March 23: Create new Lu-Solr development folder
<http://svn.apache.org/viewvc?view=revision&revision=926572>
April 6: LUCENE-2370: Reintegrate flex_1458 branch into trunk (revision 931101)
<http://svn.apache.org/viewvc?view=revision&revision=931278>
On 04/30/2010 at 3:00 PM, Shai Erera wrote:
> I would take the last rev just before the first rev when flex landed,
> so that in includes as much as possible. I don't know though which rev
> is it and whether it was before/after the lucene/solr merge.
>
> Shai
>
> On Friday, April 30, 2010, Chris Hostetter <ho...@fucit.org>
> wrote:
> >
> > > * Cut a stable branch off of trunk back before flex landed. Does
> > > anyone have any suggestions of which rev...?
> >
> > shouldn't this just be the same as the lucene/java/branches/lucene_3_0
> > branch that already exists? ... but with solr merged in?
> >
> >
> >
> > -Hoss
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
>
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Shai Erera <se...@gmail.com>.
I would take the last rev just before the first rev when flex landed,
so that in includes as much as possible. I don't know though which rev
is it and whether it was before/after the lucene/solr merge.
Shai
On Friday, April 30, 2010, Chris Hostetter <ho...@fucit.org> wrote:
>
> : * Cut a stable branch off of trunk back before flex landed. Does
> : anyone have any suggestions of which rev...?
>
> shouldn't this just be the same as the lucene/java/branches/lucene_3_0
> branch that already exists? ... but with solr merged in?
>
>
>
> -Hoss
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Chris Hostetter <ho...@fucit.org>.
: * Cut a stable branch off of trunk back before flex landed. Does
: anyone have any suggestions of which rev...?
shouldn't this just be the same as the lucene/java/branches/lucene_3_0
branch that already exists? ... but with solr merged in?
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 <ma...@gmail.com> 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
>> <lu...@mikemccandless.com> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Mark Miller <ma...@gmail.com>.
+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
> <lu...@mikemccandless.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Erik Hatcher <er...@gmail.com>.
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
> <lu...@mikemccandless.com> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
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
<lu...@mikemccandless.com> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Uwe Schindler <uw...@thetaphi.de>.
+1
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Monday, April 26, 2010 6:00 PM
> To: dev@lucene.apache.org
> Subject: [VOTE] Take 2: Open up a separate line for unstable
> Solr/Lucene development
>
> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by DM Smith <dm...@gmail.com>.
On 04/26/2010 02:43 PM, Chris Hostetter wrote:
> I didn't follow the Version API relaxation thread (my fault: i thought it
> was focused solely on how we were dealing with o.a.l.Version and lots of
> smart people were talking in ernest so i left it to them to make smart
> choices) but looking at this proposal, I'm at a loss to understand how
> it's any differnet then what we do today: we have a trunk, we add lots of
> features, and we document when compatibility breaks (and as a result rev
> our version numbers accordingly) ... in contrast, we have the "release
> branches" where we backport changes that don't break compatibility. the
> only distinction seems to be this sentence...
>
> : 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).
>
> ...i don't know that anyone would say we release "more often" off of hte
> existing release branches, but that seems more an issue of practice then
> procedure.
>
> So I feel like i must be missunderstanidng the goal here.
>
> My best guess: that what this is really suggesting is that "trunk"
> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
> 4.2, etc...) happen on "more stable" branches off of the major version
> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>
> If i'm wrong, then can someone please explain it to me in a concreate
> actionable way? (ie: specific examples of actions people would take
> moving forward under this new procedure)
>
As I understand it:
Your guess is correct.
The goal is to have future development not be encumbered by bw compat
maintenance.
Trunk will not try to maintain backward compatibility. (As I see it
there is no longer any point to Version in trunk.)
It probably won't have deprecations.
There will be no 3.9 release that differs from 4.0 only in deprecations
removed.
Moving from 3.x to 4.0 will require users to be deliberate and careful.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Earwin Burrfoot <ea...@gmail.com>.
I'd like to +1 on this with all my tiny non-committer might.
On Mon, Apr 26, 2010 at 23:06, Michael McCandless
<lu...@mikemccandless.com> wrote:
> This is exactly the intention behind the proposal we are voting on.
>
> Big changes, that'd be destabilizing if attempted on the stable
> branch, would be done only on unstable (= trunk).
>
> More "normal" changes, which can still include deprecations/some back
> compat, would be done on the stable branch and unstable.
>
> So, eg, rather than attempt back compat for a big change like flex, we
> would instead do it only in unstable and it'd first become "available"
> in the next .0 release.
>
> By segregating the big changes away from stable we should be able to
> keep stronger back compat on stable. We also save our resources not
> building costly back compat layers that, because of their complexity,
> bring their own problems. Also, our release numbers are more
> "standard" -- the .0 release will have major changes (unlike today
> where is has no changes except removal of deprecations).
>
> Mike
>
> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com> wrote:
>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>
>>> My best guess: that what this is really suggesting is that "trunk"
>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>
>> This is what I would like. Not sure if that's what will come from the
>> current proposal or not, but seems so to me.
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.1 release? Was: Re: [VOTE] Take 2: Open up a separate line for
unstable Solr/Lucene development
Posted by Michael McCandless <lu...@mikemccandless.com>.
Right, and we'd remove the 2 non-sophisticated :) back compat layers
in flex, and I'd make an index migration tool for 4.0.
Mike
On Mon, Apr 26, 2010 at 11:12 PM, Shai Erera <se...@gmail.com> wrote:
> I would like to think that if 3.1 is cut w/o flex (and following dependent
> issues), then we will allow people to re-commit the already committed code
> changes to the 3.1 branch before it is released. Then, flex et al. become
> the next 4.0 and 3.1 will be the first minor stable release of 3.x w/ some
> of the features that came post-flex (exercising our svn merge skills :)).
>
> Shai
>
> On Mon, Apr 26, 2010 at 11:01 PM, DM Smith <dm...@gmail.com> wrote:
>>
>> Assuming that the vote passed: I'm wondering where this leaves us for the
>> near term? How it works in practice.
>>
>> There have been a lot of recent changes and flex has landed. There are a
>> bunch of issues marked as 3.1 and many (most?) have decent patches.
>>
>> Let's suppose a 3.1 release soon. What would it be/contain and how would
>> it work?
>>
>> -- DM
>>
>> On 04/26/2010 03:55 PM, Shai Erera wrote:
>>>
>>> An interesting point was made on Version - we cannot remove it from
>>> trunk just to reintroduce it when trunk is released as .0 and then
>>> followed by .1 .2 "stable" releases … otherwise it would
>>> appear/disappear constantly :)?
>>>
>>> So I guess Versuon should go away entirely?
>>>
>>> Shai
>>>
>>> On Monday, April 26, 2010, Michael McCandless<lu...@mikemccandless.com>
>>> wrote:
>>>
>>>>
>>>> This is exactly the intention behind the proposal we are voting on.
>>>>
>>>> Big changes, that'd be destabilizing if attempted on the stable
>>>> branch, would be done only on unstable (= trunk).
>>>>
>>>> More "normal" changes, which can still include deprecations/some back
>>>> compat, would be done on the stable branch and unstable.
>>>>
>>>> So, eg, rather than attempt back compat for a big change like flex, we
>>>> would instead do it only in unstable and it'd first become "available"
>>>> in the next .0 release.
>>>>
>>>> By segregating the big changes away from stable we should be able to
>>>> keep stronger back compat on stable. We also save our resources not
>>>> building costly back compat layers that, because of their complexity,
>>>> bring their own problems. Also, our release numbers are more
>>>> "standard" -- the .0 release will have major changes (unlike today
>>>> where is has no changes except removal of deprecations).
>>>>
>>>> Mike
>>>>
>>>> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller<ma...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>>>
>>>>>>
>>>>>> My best guess: that what this is really suggesting is that "trunk"
>>>>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>>>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...;
>>>>>> 4.1.,
>>>>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>>>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>>>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>>>>>
>>>>>
>>>>> This is what I would like. Not sure if that's what will come from the
>>>>> current proposal or not, but seems so to me.
>>>>>
>>>>> --
>>>>> - Mark
>>>>>
>>>>> http://www.lucidimagination.com
>>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: 3.1 release? Was: Re: [VOTE] Take 2: Open up a separate line for
unstable Solr/Lucene development
Posted by Shai Erera <se...@gmail.com>.
I would like to think that if 3.1 is cut w/o flex (and following dependent
issues), then we will allow people to re-commit the already committed code
changes to the 3.1 branch before it is released. Then, flex et al. become
the next 4.0 and 3.1 will be the first minor stable release of 3.x w/ some
of the features that came post-flex (exercising our svn merge skills :)).
Shai
On Mon, Apr 26, 2010 at 11:01 PM, DM Smith <dm...@gmail.com> wrote:
> Assuming that the vote passed: I'm wondering where this leaves us for the
> near term? How it works in practice.
>
> There have been a lot of recent changes and flex has landed. There are a
> bunch of issues marked as 3.1 and many (most?) have decent patches.
>
> Let's suppose a 3.1 release soon. What would it be/contain and how would it
> work?
>
> -- DM
>
> On 04/26/2010 03:55 PM, Shai Erera wrote:
>
>> An interesting point was made on Version - we cannot remove it from
>> trunk just to reintroduce it when trunk is released as .0 and then
>> followed by .1 .2 "stable" releases … otherwise it would
>> appear/disappear constantly :)?
>>
>> So I guess Versuon should go away entirely?
>>
>> Shai
>>
>> On Monday, April 26, 2010, Michael McCandless<lu...@mikemccandless.com>
>> wrote:
>>
>>
>>> This is exactly the intention behind the proposal we are voting on.
>>>
>>> Big changes, that'd be destabilizing if attempted on the stable
>>> branch, would be done only on unstable (= trunk).
>>>
>>> More "normal" changes, which can still include deprecations/some back
>>> compat, would be done on the stable branch and unstable.
>>>
>>> So, eg, rather than attempt back compat for a big change like flex, we
>>> would instead do it only in unstable and it'd first become "available"
>>> in the next .0 release.
>>>
>>> By segregating the big changes away from stable we should be able to
>>> keep stronger back compat on stable. We also save our resources not
>>> building costly back compat layers that, because of their complexity,
>>> bring their own problems. Also, our release numbers are more
>>> "standard" -- the .0 release will have major changes (unlike today
>>> where is has no changes except removal of deprecations).
>>>
>>> Mike
>>>
>>> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller<ma...@gmail.com>
>>> wrote:
>>>
>>>
>>>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>>
>>>>
>>>>> My best guess: that what this is really suggesting is that "trunk"
>>>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...;
>>>>> 4.1.,
>>>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>>>>
>>>>>
>>>> This is what I would like. Not sure if that's what will come from the
>>>> current proposal or not, but seems so to me.
>>>>
>>>> --
>>>> - Mark
>>>>
>>>> http://www.lucidimagination.com
>>>>
>>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
3.1 release? Was: Re: [VOTE] Take 2: Open up a separate line for
unstable Solr/Lucene development
Posted by DM Smith <dm...@gmail.com>.
Assuming that the vote passed: I'm wondering where this leaves us for
the near term? How it works in practice.
There have been a lot of recent changes and flex has landed. There are a
bunch of issues marked as 3.1 and many (most?) have decent patches.
Let's suppose a 3.1 release soon. What would it be/contain and how would
it work?
-- DM
On 04/26/2010 03:55 PM, Shai Erera wrote:
> An interesting point was made on Version - we cannot remove it from
> trunk just to reintroduce it when trunk is released as .0 and then
> followed by .1 .2 "stable" releases … otherwise it would
> appear/disappear constantly :)?
>
> So I guess Versuon should go away entirely?
>
> Shai
>
> On Monday, April 26, 2010, Michael McCandless<lu...@mikemccandless.com> wrote:
>
>> This is exactly the intention behind the proposal we are voting on.
>>
>> Big changes, that'd be destabilizing if attempted on the stable
>> branch, would be done only on unstable (= trunk).
>>
>> More "normal" changes, which can still include deprecations/some back
>> compat, would be done on the stable branch and unstable.
>>
>> So, eg, rather than attempt back compat for a big change like flex, we
>> would instead do it only in unstable and it'd first become "available"
>> in the next .0 release.
>>
>> By segregating the big changes away from stable we should be able to
>> keep stronger back compat on stable. We also save our resources not
>> building costly back compat layers that, because of their complexity,
>> bring their own problems. Also, our release numbers are more
>> "standard" -- the .0 release will have major changes (unlike today
>> where is has no changes except removal of deprecations).
>>
>> Mike
>>
>> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller<ma...@gmail.com> wrote:
>>
>>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>
>>>> My best guess: that what this is really suggesting is that "trunk"
>>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>>>
>>> This is what I would like. Not sure if that's what will come from the
>>> current proposal or not, but seems so to me.
>>>
>>> --
>>> - Mark
>>>
>>> http://www.lucidimagination.com
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Shai Erera <se...@gmail.com>.
An interesting point was made on Version - we cannot remove it from
trunk just to reintroduce it when trunk is released as .0 and then
followed by .1 .2 "stable" releases … otherwise it would
appear/disappear constantly :)?
So I guess Versuon should go away entirely?
Shai
On Monday, April 26, 2010, Michael McCandless <lu...@mikemccandless.com> wrote:
> This is exactly the intention behind the proposal we are voting on.
>
> Big changes, that'd be destabilizing if attempted on the stable
> branch, would be done only on unstable (= trunk).
>
> More "normal" changes, which can still include deprecations/some back
> compat, would be done on the stable branch and unstable.
>
> So, eg, rather than attempt back compat for a big change like flex, we
> would instead do it only in unstable and it'd first become "available"
> in the next .0 release.
>
> By segregating the big changes away from stable we should be able to
> keep stronger back compat on stable. We also save our resources not
> building costly back compat layers that, because of their complexity,
> bring their own problems. Also, our release numbers are more
> "standard" -- the .0 release will have major changes (unlike today
> where is has no changes except removal of deprecations).
>
> Mike
>
> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com> wrote:
>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>
>>> My best guess: that what this is really suggesting is that "trunk"
>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>
>> This is what I would like. Not sure if that's what will come from the
>> current proposal or not, but seems so to me.
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Chris Hostetter <ho...@fucit.org>.
: Big changes, that'd be destabilizing if attempted on the stable
: branch, would be done only on unstable (= trunk).
:
: More "normal" changes, which can still include deprecations/some back
: compat, would be done on the stable branch and unstable.
...
: By segregating the big changes away from stable we should be able to
: keep stronger back compat on stable. We also save our resources not
: building costly back compat layers that, because of their complexity,
: bring their own problems. Also, our release numbers are more
: "standard" -- the .0 release will have major changes (unlike today
: where is has no changes except removal of deprecations).
Ok .. I think i'm caught up.
My vote: +0
I like the idea changing our release/branch process so that every major
release (ie: 4.0) results in he creation of two branches: one for bug fix
release like we have now (ie: branch_4_0 where patches for releases 4.0.1
and 4.0.2 would be committed) as well as new branch for minor releases
along that major line (ie: branch_4 where patches for release in 4.1 and
4.2 would be committed instead of doing minor releases off of hte trunk
like we do now) with trunk now becoming the place where changes targeting
hte next major release (ie: 5.0, 6.0, 7.0) can be commited.
My concern is that this proposal essentially requires that our current
back compat "contract" be eliminated in favor of a looser "we'll document
what's changed and try to provide migration tools" type policy. What i
worry about is that if we do this w/o agreeing on some "higher precident"
guidelines on what exactly will be "ok" back-incompat changes to make
between major release, and what is "not ok" to hcange because it
introduces too big of a migration gap, then this could result in major
versions that are so widely differnet hte community gets fractured, with a
big chunk of users never upgrading from 4.X to 5.X because the API and
index formats are too widely different and the migration process is too
cumbersome (ahem: maven1 and maven2)
That said: I don't know that we can ever hash out where the "line which
should not be crossed" is on compat changes w/o trying stuff and seeing
what happens, and i don't personally have any better suggestions, so i'm
certianly not going to stand in the way.
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
The only correction to this example is...
It's entirely possible m2 was backported to stable, and users see this
on upgrading to the next minor release.
It's only for changes that are not back-ported to stable where this
example applies, and I agree -- we have to do a strong job documenting
the migration for these trunk(unstable)-only changes.
Mike
On Tue, Apr 27, 2010 at 1:27 AM, Doron Cohen <cd...@gmail.com> wrote:
> +1
>
> I would like to note (and depict) one aspect of this change (although it is
> most probably clear to active followers of these threads).
> Deprecation warnings had been quite useful for users when upgrading to a
> *major* release.
> The voted change cancels them.
> Example follows.
> Picture the following state in the "new Lucene life cycle":
> Stable is "feeding" release 8.
> Most recent minor release is 8.4.
> Trunk will soon "feed" release 9,
> In 8.4 there is method m1(x).
> In trunk, m1(x) is renamed to m2(x,y).
> With this suggestion, in trunk, m1(x) is dropped and m2(x,y) is introduced.
> No deprecations!
> In stable, that is 8, no change is introduced at all - it is not possible to
> put a deprecate warning there since m2(x,y) is not there.
> Now, when 9.0 is finally cut from stable and released, we will *not* first
> cut 8.last with deprecation warning, because that usually goes with
> implementing the deprecated logic using the non-deprecated one, which is (a)
> not always feasible and (b) a burden that this whole change is trying to
> avoid.
> So, from now on, deprecation warnings would not be there to help users when
> upgrading to the next major release.
> Only documentation would guide them.
> Therefore, when committing such a change, it would be very important to
> adequately update the tbd evolving upgrade guide.
> Doron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, Apr 27, 2010 at 2:43 PM, Grant Ingersoll <gs...@apache.org> wrote:
> Isn't there a tool out there that automatically generates the changes in APIs?
jdiff (http://www.jdiff.org/) is pretty good.
BR,
Jukka Zitting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Grant Ingersoll <gs...@apache.org>.
I think this is a pretty important point.
Isn't there a tool out there that automatically generates the changes in APIs? I seem to recall seeing one. Perhaps even IntelliJ has one built in? Obviously, one could generate the svn diffs, but that will be too verbose.
-Grant
On Apr 27, 2010, at 1:27 AM, Doron Cohen wrote:
> +1
>
> I would like to note (and depict) one aspect of this change (although it is most probably clear to active followers of these threads).
>
> Deprecation warnings had been quite useful for users when upgrading to a *major* release.
> The voted change cancels them.
> Example follows.
>
> Picture the following state in the "new Lucene life cycle":
> Stable is "feeding" release 8.
> Most recent minor release is 8.4.
> Trunk will soon "feed" release 9,
> In 8.4 there is method m1(x).
> In trunk, m1(x) is renamed to m2(x,y).
> With this suggestion, in trunk, m1(x) is dropped and m2(x,y) is introduced. No deprecations!
> In stable, that is 8, no change is introduced at all - it is not possible to put a deprecate warning there since m2(x,y) is not there.
> Now, when 9.0 is finally cut from stable and released, we will *not* first cut 8.last with deprecation warning, because that usually goes with implementing the deprecated logic using the non-deprecated one, which is (a) not always feasible and (b) a burden that this whole change is trying to avoid.
>
> So, from now on, deprecation warnings would not be there to help users when upgrading to the next major release.
> Only documentation would guide them.
> Therefore, when committing such a change, it would be very important to adequately update the tbd evolving upgrade guide.
>
> Doron
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Doron Cohen <cd...@gmail.com>.
+1
I would like to note (and depict) one aspect of this change (although it is
most probably clear to active followers of these threads).
Deprecation warnings had been quite useful for users when upgrading to a
*major* release.
The voted change cancels them.
Example follows.
Picture the following state in the "new Lucene life cycle":
Stable is "feeding" release 8.
Most recent minor release is 8.4.
Trunk will soon "feed" release 9,
In 8.4 there is method m1(x).
In trunk, m1(x) is renamed to m2(x,y).
With this suggestion, in trunk, m1(x) is dropped and m2(x,y) is introduced.
No deprecations!
In stable, that is 8, no change is introduced at all - it is not possible to
put a deprecate warning there since m2(x,y) is not there.
Now, when 9.0 is finally cut from stable and released, we will *not* first
cut 8.last with deprecation warning, because that usually goes with
implementing the deprecated logic using the non-deprecated one, which is (a)
not always feasible and (b) a burden that this whole change is trying to
avoid.
So, from now on, deprecation warnings would not be there to help users when
upgrading to the next major release.
Only documentation would guide them.
Therefore, when committing such a change, it would be very important to
adequately update the tbd evolving upgrade guide.
Doron
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
Right, we should not require contributors to also merge down to stable
("beggars can't be choosers" ;) ).
Devs should that, and whether it's the dev who committed, or a dev who
periodically sweeps, can be worked out over time.
But Uwe should lay down the law :) Eg, we should always use "svn
merge" so the merge props are properly tracked, so that periodic
sweeping is straightforward.
Mike
On Mon, Apr 26, 2010 at 11:25 PM, Shai Erera <se...@gmail.com> wrote:
> My understanding is that "Joe Contributor" will not be forced to prepare a
> patch against "stable", but will be appreciated if he does :).
>
> The mechanics for "Joe Committer" is undecided yet. What's clear is that Joe
> cannot say "I don't care about stable for this issue, therefore I cannot
> backport it". The decision on backporting will be done per issue/patch.
> Whether it will be backported immediately (as part of that issue), or later
> on as part of a periodic stable/trunk sync, is undecided yet.
>
> A minor correction:
>>
>> they do stable or vice versa
>
> there is no "stable or vice versa" - everything must be put on trunk (unless
> it really doesn't belong there, because e.g. the API no longer exists). Many
> things will most likely get backported to stable.
>
> Shai
>
> On Tue, Apr 27, 2010 at 12:46 AM, Grant Ingersoll <gs...@apache.org>
> wrote:
>>
>> +0.9
>>
>> What are the requirements of me, "Joe Committer" and of "Joe Contributor"
>> in regards to submitting/committing patches?
>>
>> For Joe Committer, am I required to put everything on stable and trunk or
>> can I just pick trunk and if someone else wants it they do stable or vice
>> versa?
>>
>> Likewise for Joe Contributor, must I generate two patches now?
>>
>>
>> On Apr 26, 2010, at 3:06 PM, Michael McCandless wrote:
>>
>> > This is exactly the intention behind the proposal we are voting on.
>> >
>> > Big changes, that'd be destabilizing if attempted on the stable
>> > branch, would be done only on unstable (= trunk).
>> >
>> > More "normal" changes, which can still include deprecations/some back
>> > compat, would be done on the stable branch and unstable.
>> >
>> > So, eg, rather than attempt back compat for a big change like flex, we
>> > would instead do it only in unstable and it'd first become "available"
>> > in the next .0 release.
>> >
>> > By segregating the big changes away from stable we should be able to
>> > keep stronger back compat on stable. We also save our resources not
>> > building costly back compat layers that, because of their complexity,
>> > bring their own problems. Also, our release numbers are more
>> > "standard" -- the .0 release will have major changes (unlike today
>> > where is has no changes except removal of deprecations).
>> >
>> > Mike
>> >
>> > On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com>
>> > wrote:
>> >> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>> >>>
>> >>> My best guess: that what this is really suggesting is that "trunk"
>> >>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>> >>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...;
>> >>> 4.1.,
>> >>> 4.2, etc...) happen on "more stable" branches off of the major version
>> >>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>> >>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>> >>
>> >> This is what I would like. Not sure if that's what will come from the
>> >> current proposal or not, but seems so to me.
>> >>
>> >> --
>> >> - Mark
>> >>
>> >> http://www.lucidimagination.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Shai Erera <se...@gmail.com>.
My understanding is that "Joe Contributor" will not be forced to prepare a
patch against "stable", but will be appreciated if he does :).
The mechanics for "Joe Committer" is undecided yet. What's clear is that Joe
cannot say "I don't care about stable for this issue, therefore I cannot
backport it". The decision on backporting will be done per issue/patch.
Whether it will be backported immediately (as part of that issue), or later
on as part of a periodic stable/trunk sync, is undecided yet.
A minor correction:
> they do stable or vice versa
>
there is no "stable or vice versa" - everything must be put on trunk (unless
it really doesn't belong there, because e.g. the API no longer exists). Many
things will most likely get backported to stable.
Shai
On Tue, Apr 27, 2010 at 12:46 AM, Grant Ingersoll <gs...@apache.org>wrote:
> +0.9
>
> What are the requirements of me, "Joe Committer" and of "Joe Contributor"
> in regards to submitting/committing patches?
>
> For Joe Committer, am I required to put everything on stable and trunk or
> can I just pick trunk and if someone else wants it they do stable or vice
> versa?
>
> Likewise for Joe Contributor, must I generate two patches now?
>
>
> On Apr 26, 2010, at 3:06 PM, Michael McCandless wrote:
>
> > This is exactly the intention behind the proposal we are voting on.
> >
> > Big changes, that'd be destabilizing if attempted on the stable
> > branch, would be done only on unstable (= trunk).
> >
> > More "normal" changes, which can still include deprecations/some back
> > compat, would be done on the stable branch and unstable.
> >
> > So, eg, rather than attempt back compat for a big change like flex, we
> > would instead do it only in unstable and it'd first become "available"
> > in the next .0 release.
> >
> > By segregating the big changes away from stable we should be able to
> > keep stronger back compat on stable. We also save our resources not
> > building costly back compat layers that, because of their complexity,
> > bring their own problems. Also, our release numbers are more
> > "standard" -- the .0 release will have major changes (unlike today
> > where is has no changes except removal of deprecations).
> >
> > Mike
> >
> > On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com>
> wrote:
> >> On 4/26/10 2:43 PM, Chris Hostetter wrote:
> >>>
> >>> My best guess: that what this is really suggesting is that "trunk"
> >>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
> >>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...;
> 4.1.,
> >>> 4.2, etc...) happen on "more stable" branches off of the major version
> >>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
> >>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
> >>
> >> This is what I would like. Not sure if that's what will come from the
> >> current proposal or not, but seems so to me.
> >>
> >> --
> >> - Mark
> >>
> >> http://www.lucidimagination.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene development
Posted by Grant Ingersoll <gs...@apache.org>.
+0.9
What are the requirements of me, "Joe Committer" and of "Joe Contributor" in regards to submitting/committing patches?
For Joe Committer, am I required to put everything on stable and trunk or can I just pick trunk and if someone else wants it they do stable or vice versa?
Likewise for Joe Contributor, must I generate two patches now?
On Apr 26, 2010, at 3:06 PM, Michael McCandless wrote:
> This is exactly the intention behind the proposal we are voting on.
>
> Big changes, that'd be destabilizing if attempted on the stable
> branch, would be done only on unstable (= trunk).
>
> More "normal" changes, which can still include deprecations/some back
> compat, would be done on the stable branch and unstable.
>
> So, eg, rather than attempt back compat for a big change like flex, we
> would instead do it only in unstable and it'd first become "available"
> in the next .0 release.
>
> By segregating the big changes away from stable we should be able to
> keep stronger back compat on stable. We also save our resources not
> building costly back compat layers that, because of their complexity,
> bring their own problems. Also, our release numbers are more
> "standard" -- the .0 release will have major changes (unlike today
> where is has no changes except removal of deprecations).
>
> Mike
>
> On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com> wrote:
>> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>>
>>> My best guess: that what this is really suggesting is that "trunk"
>>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>>> 4.2, etc...) happen on "more stable" branches off of the major version
>>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>>
>> This is what I would like. Not sure if that's what will come from the
>> current proposal or not, but seems so to me.
>>
>> --
>> - Mark
>>
>> http://www.lucidimagination.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Michael McCandless <lu...@mikemccandless.com>.
This is exactly the intention behind the proposal we are voting on.
Big changes, that'd be destabilizing if attempted on the stable
branch, would be done only on unstable (= trunk).
More "normal" changes, which can still include deprecations/some back
compat, would be done on the stable branch and unstable.
So, eg, rather than attempt back compat for a big change like flex, we
would instead do it only in unstable and it'd first become "available"
in the next .0 release.
By segregating the big changes away from stable we should be able to
keep stronger back compat on stable. We also save our resources not
building costly back compat layers that, because of their complexity,
bring their own problems. Also, our release numbers are more
"standard" -- the .0 release will have major changes (unlike today
where is has no changes except removal of deprecations).
Mike
On Mon, Apr 26, 2010 at 2:55 PM, Mark Miller <ma...@gmail.com> wrote:
> On 4/26/10 2:43 PM, Chris Hostetter wrote:
>>
>> My best guess: that what this is really suggesting is that "trunk"
>> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
>> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
>> 4.2, etc...) happen on "more stable" branches off of the major version
>> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
>> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
>
> This is what I would like. Not sure if that's what will come from the
> current proposal or not, but seems so to me.
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Mark Miller <ma...@gmail.com>.
On 4/26/10 2:43 PM, Chris Hostetter wrote:
> My best guess: that what this is really suggesting is that "trunk"
> *always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
> etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
> 4.2, etc...) happen on "more stable" branches off of the major version
> release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
> branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
This is what I would like. Not sure if that's what will come from the
current proposal or not, but seems so to me.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Take 2: Open up a separate line for unstable Solr/Lucene
development
Posted by Chris Hostetter <ho...@fucit.org>.
I didn't follow the Version API relaxation thread (my fault: i thought it
was focused solely on how we were dealing with o.a.l.Version and lots of
smart people were talking in ernest so i left it to them to make smart
choices) but looking at this proposal, I'm at a loss to understand how
it's any differnet then what we do today: we have a trunk, we add lots of
features, and we document when compatibility breaks (and as a result rev
our version numbers accordingly) ... in contrast, we have the "release
branches" where we backport changes that don't break compatibility. the
only distinction seems to be this sentence...
: 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).
...i don't know that anyone would say we release "more often" off of hte
existing release branches, but that seems more an issue of practice then
procedure.
So I feel like i must be missunderstanidng the goal here.
My best guess: that what this is really suggesting is that "trunk"
*always* be targeted at the next "major" release (ie: 4.0, 5.0, 6.0,
etc...) and that development of minor releases (ie: 3.2, 3.3, ...; 4.1.,
4.2, etc...) happen on "more stable" branches off of the major version
release branches (ie: branch_3_0 forks off trunk when 3.0 is release,
branch_3_1 forks off branch_3_0 when 3.1 releases, etc...)
If i'm wrong, then can someone please explain it to me in a concreate
actionable way? (ie: specific examples of actions people would take
moving forward under this new procedure)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org