Release planning for 7.0

[Anshum Gupta <an...@anshumgupta.net>]

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

Re: Release planning for 7.0

[Adrien Grand <jp...@gmail.com>]

+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 <no...@gmail.com> a écrit :

> +1
>
>
> On Fri, May 5, 2017 at 2:28 AM, Anshum Gupta <an...@anshumgupta.net>
> 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 <
> tomasflobbe@gmail.com>
> > 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 <david.w.smiley@gmail.com
> >
> >> wrote:
> >>>
> >>> +1
> >>>
> >>> On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <an...@anshumgupta.net>
> >>> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Release planning for 7.0

[Noble Paul <no...@gmail.com>]

+1


On Fri, May 5, 2017 at 2:28 AM, Anshum Gupta <an...@anshumgupta.net> 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 <to...@gmail.com>
> 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 <da...@gmail.com>
>> wrote:
>>>
>>> +1
>>>
>>> On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <an...@anshumgupta.net>
>>> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release planning for 7.0

[Anshum Gupta <an...@anshumgupta.net>]

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 <to...@gmail.com>
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 <da...@gmail.com>
> wrote:
>
>> +1
>>
>> On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <an...@anshumgupta.net>
>> 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
>>
>
>

Re: Release planning for 7.0

[Tomás Fernández Löbbe <to...@gmail.com>]

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 <da...@gmail.com>
wrote:

> +1
>
> On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <an...@anshumgupta.net>
> 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
>

Re: Release planning for 7.0

[David Smiley <da...@gmail.com>]

+1

On Wed, May 3, 2017 at 11:56 AM Anshum Gupta <an...@anshumgupta.net> 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

Re: Release planning for 7.0

[Ishan Chattopadhyaya <ic...@gmail.com>]

> 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 <an...@anshumgupta.net> 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
>

Re: Release planning for 7.0

[Erick Erickson <er...@gmail.com>]

I think people are missing my point. I am _not_ advocating having "two
major feature branches developed at once". I'm pointing out that
between now and the 7.0 release (and possibly for a bit thereafter),
there will be a number of JIRAs that _could_ be backported to a
(future) 6.7 with virtually no effort. Some of these will be quite
helpful to clients. Trust me on this.

There's no good reason to _artificially_ refuse to backport a JIRA if
it's easy just because "we're releasing 7.0". It always takes a while
for the next major version to burn in so there's this gray period
between when 7.0 is cut and when 7.0.x will have enough mileage on it
to be the go-to version for production systems. The key here is "if
it's easy".

I'm _not_ advocating that every new commit to 7x has to be backported.
If it doesn't backport cleanly with near-zero effort, don't bother. If
you're working on a nifty new feature that would require extra work to
back-port to 6x, don't bother.

If you can back-port it in 5 minutes with a simple merge between now
and when 7.0.x becomes our go-to, please consider it.

I also suspect that many of the Lucene-level changes are far more
difficult to back-port than many of the Solr changes, the Lucene code
has to deal with gnarly back-compat issues a lot more. So I'd rather
expect that many Lucene changes can't get back-ported because it's not
easy, especially when all the deprecated code is removed, which is
fine.

Just let's not automatically exclude the idea of back-porting a JIRA
to 6x if it can be done with minimal effort just because 7.0 is being
planned.

We've always had JIRAs back-ported to newest_release-1x to be picked
up _if_ there's another release along that branch, so I don't
understand why this is at all controversial.

Best,
Erick

On Thu, May 25, 2017 at 7:18 AM, Michael McCandless
<lu...@mikemccandless.com> wrote:
> On Thu, May 25, 2017 at 9:16 AM, David Smiley <da...@gmail.com>
> wrote:
>>
>> On Thu, May 25, 2017 at 9:06 AM Shawn Heisey <ap...@elyograg.org> 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?
>
>
> It's more than just an RM volunteer to do another 6.x feature release; it's
> also our collective effort to back-port features to 6.x, to spend limited CI
> resources running 6.x tests, etc.
>
>> I think there's nothing wrong with a 6.whatever release following a 7.0.
>
>
> I don't think that makes much sense.
>
> Why would we choose to have two major feature branches developed at once?
> Once 7.0 is out, we should work hard towards the next (7.1) feature release,
> and leave 6.6.x open only for bug fixes.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release planning for 7.0

[Michael McCandless <lu...@mikemccandless.com>]

On Thu, May 25, 2017 at 9:16 AM, David Smiley <da...@gmail.com>
wrote:

> On Thu, May 25, 2017 at 9:06 AM Shawn Heisey <ap...@elyograg.org> 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?
>

It's more than just an RM volunteer to do another 6.x feature release; it's
also our collective effort to back-port features to 6.x, to spend limited
CI resources running 6.x tests, etc.

I think there's nothing wrong with a 6.whatever release following a 7.0.
>

I don't think that makes much sense.

Why would we choose to have two major feature branches developed at once?
Once 7.0 is out, we should work hard towards the next (7.1) feature
release, and leave 6.6.x open only for bug fixes.

Mike McCandless

http://blog.mikemccandless.com

Re: Release planning for 7.0

[David Smiley <da...@gmail.com>]

On Thu, May 25, 2017 at 9:06 AM Shawn Heisey <ap...@elyograg.org> 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
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Release planning for 7.0

[Shawn Heisey <ap...@elyograg.org>]

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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release planning for 7.0

[Joel Bernstein <jo...@gmail.com>]

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.

Joel Bernstein
http://joelsolr.blogspot.com/

On Wed, May 24, 2017 at 7:13 PM, Anshum Gupta <an...@anshumgupta.net>
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 <jp...@gmail.com> wrote:
>
>> Le mar. 23 mai 2017 à 20:01, Shawn Heisey <ap...@elyograg.org> 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.
>>
>

Re: Release planning for 7.0

[Anshum Gupta <an...@anshumgupta.net>]

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 <jp...@gmail.com> wrote:

> Le mar. 23 mai 2017 à 20:01, Shawn Heisey <ap...@elyograg.org> 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.
>

Re: Release planning for 7.0

[Adrien Grand <jp...@gmail.com>]

Le mar. 23 mai 2017 à 20:01, Shawn Heisey <ap...@elyograg.org> 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.

Re: Release planning for 7.0

[Shawn Heisey <ap...@elyograg.org>]

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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release planning for 7.0

[Joel Bernstein <jo...@gmail.com>]

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

Joel Bernstein
http://joelsolr.blogspot.com/

On Tue, May 23, 2017 at 11:47 AM, Adrien Grand <jp...@gmail.com> wrote:

> Le mar. 23 mai 2017 à 17:15, Erick Erickson <er...@gmail.com> 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.
>

Re: Release planning for 7.0

[Erick Erickson <er...@gmail.com>]

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 <jp...@gmail.com> wrote:
> Le mar. 23 mai 2017 à 17:15, Erick Erickson <er...@gmail.com> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release planning for 7.0

[Adrien Grand <jp...@gmail.com>]

Le mar. 23 mai 2017 à 17:15, Erick Erickson <er...@gmail.com> 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.

Re: Release planning for 7.0

[David Smiley <da...@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 <er...@gmail.com>
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 <an...@anshumgupta.net>
> 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 <ja...@cominvent.com>
> 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 <an...@anshumgupta.net>:
> >>
> >> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Release planning for 7.0

[Erick Erickson <er...@gmail.com>]

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 <an...@anshumgupta.net> 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 <ja...@cominvent.com> 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 <an...@anshumgupta.net>:
>>
>> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Release planning for 7.0

[Anshum Gupta <an...@anshumgupta.net>]

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
<https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20fixVersion%20%3D%20%22master%20(7.0)%22%20AND%20resolution%20%3D%20Unresolved%20AND%20priority%20in%20(Blocker%2C%20Critical)%20ORDER%20BY%20key%20DESC>

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 <ja...@cominvent.com> 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 <an...@anshumgupta.net>:
>
> 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
>
>
>

Re: Release planning for 7.0

[Jan Høydahl <ja...@cominvent.com>]

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 <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 <an...@anshumgupta.net>:
> 
> 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