Release planning for 7.0

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Release planning for 7.0

Anshum Gupta
Hi,

It's May already, and with 6.6 lined up, I think we should start planning on how we want to proceed with 7.0, in terms of both - the timeline, and what it would likely contain.

I am not suggesting we start the release process right away, but just wanted to start a discussion around the above mentioned lines.

With 6.6 in the pipeline, I think sometime in June would be a good time to cut a release branch. What do all of you think?

P.S: This email is about 'discussion' and 'planning', so if someone wants to volunteer to be the release manager, please go ahead. I can't remember if someone did explicit volunteer to wear this hat for 7.0. If no one volunteers, I will take it up.

-Anshum
Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Ishan Chattopadhyaya
> With 6.6 in the pipeline, I think sometime in June would be a good time to cut a release
> branch. What do all of you think?

+1

On Wed, May 3, 2017 at 9:11 PM, Anshum Gupta <[hidden email]> wrote:
Hi,

It's May already, and with 6.6 lined up, I think we should start planning on how we want to proceed with 7.0, in terms of both - the timeline, and what it would likely contain.

I am not suggesting we start the release process right away, but just wanted to start a discussion around the above mentioned lines.

With 6.6 in the pipeline, I think sometime in June would be a good time to cut a release branch. What do all of you think?

P.S: This email is about 'discussion' and 'planning', so if someone wants to volunteer to be the release manager, please go ahead. I can't remember if someone did explicit volunteer to wear this hat for 7.0. If no one volunteers, I will take it up.

-Anshum

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

david.w.smiley@gmail.com
In reply to this post by Anshum Gupta
+1

On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <[hidden email]> wrote:
With 6.6 in the pipeline, I think sometime in June would be a good time to cut a release branch. What do all of you think?
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Tomás Fernández Löbbe
One thing I'd like to get to 7.0 is replica types (SOLR-10233). Most of the work is done, I'm working on more tests right now. If everything works fine I should be committing that some time next week.

Tomás

On Wed, May 3, 2017 at 10:33 AM, David Smiley <[hidden email]> wrote:
+1

On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <[hidden email]> wrote:
With 6.6 in the pipeline, I think sometime in June would be a good time to cut a release branch. What do all of you think?
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Anshum Gupta
That sounds great Tomas.

Also, if we go with my suggestion, everyone has one more month before the branch is cut.

-Anshum

On Thu, May 4, 2017 at 9:51 AM Tomás Fernández Löbbe <[hidden email]> wrote:
One thing I'd like to get to 7.0 is replica types (SOLR-10233). Most of the work is done, I'm working on more tests right now. If everything works fine I should be committing that some time next week.

Tomás

On Wed, May 3, 2017 at 10:33 AM, David Smiley <[hidden email]> wrote:
+1

On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <[hidden email]> wrote:
With 6.6 in the pipeline, I think sometime in June would be a good time to cut a release branch. What do all of you think?
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Noble Paul നോബിള്‍  नोब्ळ्
+1


On Fri, May 5, 2017 at 2:28 AM, Anshum Gupta <[hidden email]> wrote:

> That sounds great Tomas.
>
> Also, if we go with my suggestion, everyone has one more month before the
> branch is cut.
>
> -Anshum
>
> On Thu, May 4, 2017 at 9:51 AM Tomás Fernández Löbbe <[hidden email]>
> wrote:
>>
>> One thing I'd like to get to 7.0 is replica types (SOLR-10233). Most of
>> the work is done, I'm working on more tests right now. If everything works
>> fine I should be committing that some time next week.
>>
>> Tomás
>>
>> On Wed, May 3, 2017 at 10:33 AM, David Smiley <[hidden email]>
>> wrote:
>>>
>>> +1
>>>
>>> On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <[hidden email]>
>>> wrote:
>>>>
>>>> With 6.6 in the pipeline, I think sometime in June would be a good time
>>>> to cut a release branch. What do all of you think?
>>>
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>
>>
>



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Adrien Grand
+1 I'd like to get https://issues.apache.org/jira/browse/LUCENE-7730 in as it can only be done in a major release. I'll review our documentation as well after all the changes we made to doc values and similarities.

Le jeu. 4 mai 2017 à 23:20, Noble Paul <[hidden email]> a écrit :
+1


On Fri, May 5, 2017 at 2:28 AM, Anshum Gupta <[hidden email]> wrote:
> That sounds great Tomas.
>
> Also, if we go with my suggestion, everyone has one more month before the
> branch is cut.
>
> -Anshum
>
> On Thu, May 4, 2017 at 9:51 AM Tomás Fernández Löbbe <[hidden email]>
> wrote:
>>
>> One thing I'd like to get to 7.0 is replica types (SOLR-10233). Most of
>> the work is done, I'm working on more tests right now. If everything works
>> fine I should be committing that some time next week.
>>
>> Tomás
>>
>> On Wed, May 3, 2017 at 10:33 AM, David Smiley <[hidden email]>
>> wrote:
>>>
>>> +1
>>>
>>> On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <[hidden email]>
>>> wrote:
>>>>
>>>> With 6.6 in the pipeline, I think sometime in June would be a good time
>>>> to cut a release branch. What do all of you think?
>>>
>>> --
>>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>
>>
>



--
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Jan Høydahl / Cominvent
In reply to this post by Anshum Gupta
I think it would be great if 7.0 could have a platform independent solr.in.xx format
https://issues.apache.org/jira/browse/SOLR-7871 contains work in progress… Anyone want to help?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

3. mai 2017 kl. 17.41 skrev Anshum Gupta <[hidden email]>:

Hi,

It's May already, and with 6.6 lined up, I think we should start planning on how we want to proceed with 7.0, in terms of both - the timeline, and what it would likely contain.

I am not suggesting we start the release process right away, but just wanted to start a discussion around the above mentioned lines.

With 6.6 in the pipeline, I think sometime in June would be a good time to cut a release branch. What do all of you think?

P.S: This email is about 'discussion' and 'planning', so if someone wants to volunteer to be the release manager, please go ahead. I can't remember if someone did explicit volunteer to wear this hat for 7.0. If no one volunteers, I will take it up.

-Anshum

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Anshum Gupta
I plan on cutting the release branch on (or right after 10th of June). Does that sound reasonable to everyone?

There are 4 Blocker/Critical issues in Solr at the moment w/ fix version 'master':

There are no Blocker/Critical issues in Lucene at the moment w/ fix version 'master':

If there are any issues that should be resolved before 7.0, this would be a good time to do so. Once we have the 7.0 branch, we should not be adding new features to it until the release.

-Anshum

On Fri, May 5, 2017 at 7:01 AM Jan Høydahl <[hidden email]> wrote:
I think it would be great if 7.0 could have a platform independent solr.in.xx format
https://issues.apache.org/jira/browse/SOLR-7871 contains work in progress… Anyone want to help?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

3. mai 2017 kl. 17.41 skrev Anshum Gupta <[hidden email]>:

Hi,

It's May already, and with 6.6 lined up, I think we should start planning on how we want to proceed with 7.0, in terms of both - the timeline, and what it would likely contain.

I am not suggesting we start the release process right away, but just wanted to start a discussion around the above mentioned lines.

With 6.6 in the pipeline, I think sometime in June would be a good time to cut a release branch. What do all of you think?

P.S: This email is about 'discussion' and 'planning', so if someone wants to volunteer to be the release manager, please go ahead. I can't remember if someone did explicit volunteer to wear this hat for 7.0. If no one volunteers, I will take it up.

-Anshum

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Erick Erickson
Do others expect there to be a 6.7 release? I'm guessing there'll be a
6.7, and maybe one or two 6.7.x releases while 7.x settles down and/or
we want to put a bow on the 6x code line.

Really a plea for people not to assume that the 6x code line is
moribund for a bit, and merge changes into 6x if it's easy. Up to
individuals of course.

Anshum:

Not suggesting you have to do anything for 6.x here...

On Tue, May 23, 2017 at 7:58 AM, Anshum Gupta <[hidden email]> wrote:

> I plan on cutting the release branch on (or right after 10th of June). Does
> that sound reasonable to everyone?
>
> There are 4 Blocker/Critical issues in Solr at the moment w/ fix version
> 'master':
> https://issues.apache.org/jira/browse/SOLR/fixforversion/12335718/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel
>
> There are no Blocker/Critical issues in Lucene at the moment w/ fix version
> 'master':
> https://issues.apache.org/jira/browse/LUCENE/fixforversion/12335717/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel
>
> If there are any issues that should be resolved before 7.0, this would be a
> good time to do so. Once we have the 7.0 branch, we should not be adding new
> features to it until the release.
>
> -Anshum
>
> On Fri, May 5, 2017 at 7:01 AM Jan Høydahl <[hidden email]> wrote:
>>
>> I think it would be great if 7.0 could have a platform independent
>> solr.in.xx format
>> https://issues.apache.org/jira/browse/SOLR-7871 contains work in progress…
>> Anyone want to help?
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>> 3. mai 2017 kl. 17.41 skrev Anshum Gupta <[hidden email]>:
>>
>> Hi,
>>
>> It's May already, and with 6.6 lined up, I think we should start planning
>> on how we want to proceed with 7.0, in terms of both - the timeline, and
>> what it would likely contain.
>>
>> I am not suggesting we start the release process right away, but just
>> wanted to start a discussion around the above mentioned lines.
>>
>> With 6.6 in the pipeline, I think sometime in June would be a good time to
>> cut a release branch. What do all of you think?
>>
>> P.S: This email is about 'discussion' and 'planning', so if someone wants
>> to volunteer to be the release manager, please go ahead. I can't remember if
>> someone did explicit volunteer to wear this hat for 7.0. If no one
>> volunteers, I will take it up.
>>
>> -Anshum
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

david.w.smiley@gmail.com
Agreed; I plan to back port some issues on occasion to 6.x still.

On Tue, May 23, 2017 at 11:15 AM Erick Erickson <[hidden email]> wrote:
Do others expect there to be a 6.7 release? I'm guessing there'll be a
6.7, and maybe one or two 6.7.x releases while 7.x settles down and/or
we want to put a bow on the 6x code line.

Really a plea for people not to assume that the 6x code line is
moribund for a bit, and merge changes into 6x if it's easy. Up to
individuals of course.

Anshum:

Not suggesting you have to do anything for 6.x here...

On Tue, May 23, 2017 at 7:58 AM, Anshum Gupta <[hidden email]> wrote:
> I plan on cutting the release branch on (or right after 10th of June). Does
> that sound reasonable to everyone?
>
> There are 4 Blocker/Critical issues in Solr at the moment w/ fix version
> 'master':
> https://issues.apache.org/jira/browse/SOLR/fixforversion/12335718/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel
>
> There are no Blocker/Critical issues in Lucene at the moment w/ fix version
> 'master':
> https://issues.apache.org/jira/browse/LUCENE/fixforversion/12335717/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel
>
> If there are any issues that should be resolved before 7.0, this would be a
> good time to do so. Once we have the 7.0 branch, we should not be adding new
> features to it until the release.
>
> -Anshum
>
> On Fri, May 5, 2017 at 7:01 AM Jan Høydahl <[hidden email]> wrote:
>>
>> I think it would be great if 7.0 could have a platform independent
>> solr.in.xx format
>> https://issues.apache.org/jira/browse/SOLR-7871 contains work in progress…
>> Anyone want to help?
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>> 3. mai 2017 kl. 17.41 skrev Anshum Gupta <[hidden email]>:
>>
>> Hi,
>>
>> It's May already, and with 6.6 lined up, I think we should start planning
>> on how we want to proceed with 7.0, in terms of both - the timeline, and
>> what it would likely contain.
>>
>> I am not suggesting we start the release process right away, but just
>> wanted to start a discussion around the above mentioned lines.
>>
>> With 6.6 in the pipeline, I think sometime in June would be a good time to
>> cut a release branch. What do all of you think?
>>
>> P.S: This email is about 'discussion' and 'planning', so if someone wants
>> to volunteer to be the release manager, please go ahead. I can't remember if
>> someone did explicit volunteer to wear this hat for 7.0. If no one
>> volunteers, I will take it up.
>>
>> -Anshum
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Adrien Grand
In reply to this post by Erick Erickson
Le mar. 23 mai 2017 à 17:15, Erick Erickson <[hidden email]> a écrit :
Do others expect there to be a 6.7 release? I'm guessing there'll be a
6.7, and maybe one or two 6.7.x releases while 7.x settles down and/or
we want to put a bow on the 6x code line.

Once 7.0 is out, releasing 6.x becomes trickier since we need to make sure not only that it can read all previous versions, but also that new versions (7.x) can read it. I'm not suggesting we do not do any release at all: we should still do bugfix releases when important bugs are discovered. Since bugfix releases tend to have contained change logs, it is easier to reason about what could go wrong so we just need to be a bit more careful. However I think we should avoid releasing new 6.x minor releases once 7.0 is out.
Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Joel Bernstein
I would like to have a 6.7 release if possible, to wrap up some features for users in the 6x branch. 


On Tue, May 23, 2017 at 11:47 AM, Adrien Grand <[hidden email]> wrote:
Le mar. 23 mai 2017 à 17:15, Erick Erickson <[hidden email]> a écrit :
Do others expect there to be a 6.7 release? I'm guessing there'll be a
6.7, and maybe one or two 6.7.x releases while 7.x settles down and/or
we want to put a bow on the 6x code line.

Once 7.0 is out, releasing 6.x becomes trickier since we need to make sure not only that it can read all previous versions, but also that new versions (7.x) can read it. I'm not suggesting we do not do any release at all: we should still do bugfix releases when important bugs are discovered. Since bugfix releases tend to have contained change logs, it is easier to reason about what could go wrong so we just need to be a bit more careful. However I think we should avoid releasing new 6.x minor releases once 7.0 is out.

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Erick Erickson
In reply to this post by Adrien Grand
Adrien:

Right, thus my "if it's easy" clause ;)

I'm not suggesting at all that we go very far down this road, more "if
it merges cleanly and makes sense, backport. Maybe. If you feel like
it".

And I'm _really_ not suggesting that we try to back-port anything that
would make our lives harder, more "let's make 6x as complete as we can
without making development too much more difficult".


Erick



On Tue, May 23, 2017 at 8:47 AM, Adrien Grand <[hidden email]> wrote:

> Le mar. 23 mai 2017 à 17:15, Erick Erickson <[hidden email]> a
> écrit :
>>
>> Do others expect there to be a 6.7 release? I'm guessing there'll be a
>> 6.7, and maybe one or two 6.7.x releases while 7.x settles down and/or
>> we want to put a bow on the 6x code line.
>
>
> Once 7.0 is out, releasing 6.x becomes trickier since we need to make sure
> not only that it can read all previous versions, but also that new versions
> (7.x) can read it. I'm not suggesting we do not do any release at all: we
> should still do bugfix releases when important bugs are discovered. Since
> bugfix releases tend to have contained change logs, it is easier to reason
> about what could go wrong so we just need to be a bit more careful. However
> I think we should avoid releasing new 6.x minor releases once 7.0 is out.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Shawn Heisey-2
In reply to this post by Erick Erickson
On 5/23/2017 9:14 AM, Erick Erickson wrote:
> Do others expect there to be a 6.7 release? I'm guessing there'll be a
> 6.7, and maybe one or two 6.7.x releases while 7.x settles down and/or
> we want to put a bow on the 6x code line.
>
> Really a plea for people not to assume that the 6x code line is
> moribund for a bit, and merge changes into 6x if it's easy. Up to
> individuals of course.

What is our plan for legacy numerics in Solr 7.0?  Looking at the
example configs in branch_6x, I see that they have been partially
converted to the point field types, but not fully.  The _version_ field
and many dynamic fields are still using Trie types.

If legacy numerics disappear from Solr 7.0 (since normal deprecation
rules indicate they will be gone from Lucene 7.0), very few 6.x users
will be able to upgrade to 7.0 without redesigning and completely
rebuilding their indexes.

Regarding Adrien's concern, if the index format doesn't change and
existing analysis components don't do anything radically different, it
should be pretty safe to fix minor problems and backport self-contained
features in 6.x releases after 7.0 hits.

Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Adrien Grand
Le mar. 23 mai 2017 à 20:01, Shawn Heisey <[hidden email]> a écrit :
What is our plan for legacy numerics in Solr 7.0?  Looking at the
example configs in branch_6x, I see that they have been partially
converted to the point field types, but not fully.  The _version_ field
and many dynamic fields are still using Trie types.

If legacy numerics disappear from Solr 7.0 (since normal deprecation
rules indicate they will be gone from Lucene 7.0), very few 6.x users
will be able to upgrade to 7.0 without redesigning and completely
rebuilding their indexes.

We said before that we could move it to the solr sub-folder so that Solr can support them for one additional major release (it can be done on top of Lucene, doesn't need to be supported in Lucene directly). However it is probably important to do whatever needs to be done now (ie. before 7.0 is released) so that the removal of legacy numerics will be seamless for users in 8.0. For instance maybe Solr should disallow the addition of legacy numerics to the schema of indices that are created on 7.x? Or alternatively implicitly upgrade those fields to points (for 7.x indices only, otherwise it would break old indices) if you think it provides a better user experience.

Regarding Adrien's concern, if the index format doesn't change and
existing analysis components don't do anything radically different, it
should be pretty safe to fix minor problems and backport self-contained
features in 6.x releases after 7.0 hits.

To me the best trade-off is to stop doing 6.x minor releases once 7.0 is out. It is simple and safe. And encouraging users to upgrade if they want to take advantage of new features might not be a bad thing. If we really really really want to keep releasing features in 6.x, I think we have two options: add forward-compatibility tests to make sure that all 7.x releases can read indices created by the new 6.x release, or decouple the release cycles of Lucene and Solr so that Solr can keep adding features on 6.x by staying on the exact same Lucene version. I understand the likeliness that we break forward compatibility is not high, but it can happen in unexpected ways, and if it happens it would be terrible.
Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Anshum Gupta
Do we have an idea on what/when are we looking at w.r.t a 6.7 release? 

Bug fixes that follow are totally ok, and should be released but this is more about, when do we stop adding 'new features' to the 6x branch, even if that involves back-porting.

Assuming that the 6.7 release would be some time in June, that would still be before the first 7x release happens, which to me is ok. Anything more, and it starts getting confusing to end-users. If am not opposing more 6x releases but just trying to keep things simple to manage for both, end-users, and contributors.

-Anshum


On Wed, May 24, 2017 at 12:45 AM Adrien Grand <[hidden email]> wrote:
Le mar. 23 mai 2017 à 20:01, Shawn Heisey <[hidden email]> a écrit :
What is our plan for legacy numerics in Solr 7.0?  Looking at the
example configs in branch_6x, I see that they have been partially
converted to the point field types, but not fully.  The _version_ field
and many dynamic fields are still using Trie types.

If legacy numerics disappear from Solr 7.0 (since normal deprecation
rules indicate they will be gone from Lucene 7.0), very few 6.x users
will be able to upgrade to 7.0 without redesigning and completely
rebuilding their indexes.

We said before that we could move it to the solr sub-folder so that Solr can support them for one additional major release (it can be done on top of Lucene, doesn't need to be supported in Lucene directly). However it is probably important to do whatever needs to be done now (ie. before 7.0 is released) so that the removal of legacy numerics will be seamless for users in 8.0. For instance maybe Solr should disallow the addition of legacy numerics to the schema of indices that are created on 7.x? Or alternatively implicitly upgrade those fields to points (for 7.x indices only, otherwise it would break old indices) if you think it provides a better user experience.

Regarding Adrien's concern, if the index format doesn't change and
existing analysis components don't do anything radically different, it
should be pretty safe to fix minor problems and backport self-contained
features in 6.x releases after 7.0 hits.

To me the best trade-off is to stop doing 6.x minor releases once 7.0 is out. It is simple and safe. And encouraging users to upgrade if they want to take advantage of new features might not be a bad thing. If we really really really want to keep releasing features in 6.x, I think we have two options: add forward-compatibility tests to make sure that all 7.x releases can read indices created by the new 6.x release, or decouple the release cycles of Lucene and Solr so that Solr can keep adding features on 6.x by staying on the exact same Lucene version. I understand the likeliness that we break forward compatibility is not high, but it can happen in unexpected ways, and if it happens it would be terrible.
Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Joel Bernstein
I'd like to have until June 2nd to finish up tickets for 6.7. That would give use a little leeway to get 6.7 released before starting the 7.0 release process around June 10th.


On Wed, May 24, 2017 at 7:13 PM, Anshum Gupta <[hidden email]> wrote:
Do we have an idea on what/when are we looking at w.r.t a 6.7 release? 

Bug fixes that follow are totally ok, and should be released but this is more about, when do we stop adding 'new features' to the 6x branch, even if that involves back-porting.

Assuming that the 6.7 release would be some time in June, that would still be before the first 7x release happens, which to me is ok. Anything more, and it starts getting confusing to end-users. If am not opposing more 6x releases but just trying to keep things simple to manage for both, end-users, and contributors.

-Anshum


On Wed, May 24, 2017 at 12:45 AM Adrien Grand <[hidden email]> wrote:
Le mar. 23 mai 2017 à 20:01, Shawn Heisey <[hidden email]> a écrit :
What is our plan for legacy numerics in Solr 7.0?  Looking at the
example configs in branch_6x, I see that they have been partially
converted to the point field types, but not fully.  The _version_ field
and many dynamic fields are still using Trie types.

If legacy numerics disappear from Solr 7.0 (since normal deprecation
rules indicate they will be gone from Lucene 7.0), very few 6.x users
will be able to upgrade to 7.0 without redesigning and completely
rebuilding their indexes.

We said before that we could move it to the solr sub-folder so that Solr can support them for one additional major release (it can be done on top of Lucene, doesn't need to be supported in Lucene directly). However it is probably important to do whatever needs to be done now (ie. before 7.0 is released) so that the removal of legacy numerics will be seamless for users in 8.0. For instance maybe Solr should disallow the addition of legacy numerics to the schema of indices that are created on 7.x? Or alternatively implicitly upgrade those fields to points (for 7.x indices only, otherwise it would break old indices) if you think it provides a better user experience.

Regarding Adrien's concern, if the index format doesn't change and
existing analysis components don't do anything radically different, it
should be pretty safe to fix minor problems and backport self-contained
features in 6.x releases after 7.0 hits.

To me the best trade-off is to stop doing 6.x minor releases once 7.0 is out. It is simple and safe. And encouraging users to upgrade if they want to take advantage of new features might not be a bad thing. If we really really really want to keep releasing features in 6.x, I think we have two options: add forward-compatibility tests to make sure that all 7.x releases can read indices created by the new 6.x release, or decouple the release cycles of Lucene and Solr so that Solr can keep adding features on 6.x by staying on the exact same Lucene version. I understand the likeliness that we break forward compatibility is not high, but it can happen in unexpected ways, and if it happens it would be terrible.

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Shawn Heisey-2
In reply to this post by Adrien Grand
On 5/24/2017 1:44 AM, Adrien Grand wrote:

> We said before that we could move it to the solr sub-folder so that
> Solr can support them for one additional major release (it can be done
> on top of Lucene, doesn't need to be supported in Lucene directly).
> However it is probably important to do whatever needs to be done now
> (ie. before 7.0 is released) so that the removal of legacy numerics
> will be seamless for users in 8.0. For instance maybe Solr should
> disallow the addition of legacy numerics to the schema of indices that
> are created on 7.x? Or alternatively implicitly upgrade those fields
> to points (for 7.x indices only, otherwise it would break old indices)
> if you think it provides a better user experience.

Moving the legacy numeric support to Solr for 7.x might be the way to
go.  I would prefer to have it remain in Lucene for another major
version, but I suspect there will be resistance.  I think that ES users
could also benefit from legacy support remaining in Lucene for a while
longer.

I don't know how Solr would distinguish between existing legacy numeric
fields and fields that are added later, so I'm not sure there's anything
we could do to prevent users from setting up a schema that can't be used
later.

> To me the best trade-off is to stop doing 6.x minor releases once 7.0
> is out.

I did say it would be relatively safe to do bugfixes and backport
self-contained features in 6.x after 7.0 comes out as long as care is
taken to not change the index format or analysis component behavior.

Despite saying that, I actually agree with you that new minor releases
(and therefore new features) should be avoided in the previous major
version unless there is a VERY compelling reason.  It doesn't seem very
likely that a compelling reason will be encountered.

Thanks,
Shawn


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

david.w.smiley@gmail.com
On Thu, May 25, 2017 at 9:06 AM Shawn Heisey <[hidden email]> wrote:
> To me the best trade-off is to stop doing 6.x minor releases once 7.0
> is out.

I did say it would be relatively safe to do bugfixes and backport
self-contained features in 6.x after 7.0 comes out as long as care is
taken to not change the index format or analysis component behavior.

Despite saying that, I actually agree with you that new minor releases
(and therefore new features) should be avoided in the previous major
version unless there is a VERY compelling reason.  It doesn't seem very
likely that a compelling reason will be encountered.

Why?  If someone (not you, obviously), is willing to be the RM, then what's it to you? 

I think there's nothing wrong with a 6.whatever release following a 7.0.
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
12