Release planning for 7.0

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

Re: Release planning for 7.0

Michael McCandless-2
On Thu, May 25, 2017 at 9:16 AM, David Smiley <[hidden email]> wrote:
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? 

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.


Reply | Threaded
Open this post in threaded view
|

Re: Release planning for 7.0

Erick Erickson
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
<[hidden email]> wrote:

> On Thu, May 25, 2017 at 9:16 AM, David Smiley <[hidden email]>
> wrote:
>>
>> 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?
>
>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

12