You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Doug Turnbull <dt...@opensourceconnections.com> on 2014/03/12 17:14:17 UTC

More Maintenance Releases?

Hello Solr community,

We have been using Solr to great effect at OpenSource Connections.
Occasionally though, we'll hit a bug in say 4.5.1, that gets fixed in
4.6.0. Unfortunately, as 4.6.0 is a release sporting several new features,
there's invariably new bugs that get introduced. So while my bug in 4.5.1
is fixed, a new bug related to new features in 4.6.0 means 4.6.0 might be a
showstopper.

This is more a question for the PMC than anything (with comments from
others welcome). Would it be possible to do more minor bug-fix releases? I
realize this could be a burden, so maybe it would  be good to pick a
version and decide this will be a "long term support" release. We will
backport bug fixes and do several additional bug-fix releases for 4-6
months? Then we'd pick another version to be a "long term support" release?

This would help with the overall stability of Solr and help in the decision
about how/when to upgrade Solr.

Cheers,
-- 
Doug Turnbull
Search & Big Data Architect
OpenSource Connections <http://o19s.com>

Re: More Maintenance Releases?

Posted by Shawn Heisey <so...@elyograg.org>.
On 3/12/2014 6:27 PM, Erick Erickson wrote:
> Wondering if 4.7 is a "natural" point to do this.
> 
> See Uwe's announcement that as of Solr 4.8,
> Solr/Lucene will _require_ Java 1.7 rather than
> Java 1.6.
> 
> I know some organizations will not be able to
> make this transition easily, thus I suspect we'll
> see ongoing requests to "please back-port XXX
> to Solr 4.7 since we can't use Java 1.7). Hmmm,
> Solr 4.7, Java 1.7, coincidence? :).
> 
> Does it make any sense to think of essentially
> freezing 4.7 except for bug fixes that we selectively
> back-port?

It's possible, even likely, that we'll end up doing a number of 4.7.x
releases specifically because an important group of users can't upgrade
Java.  Those releases will probably happen on a longer timescale than
the minor releases, and I would not expect a large number of new
features to be backported.

The hassles involved in backporting across the Java 6 version boundary
might prove to be an accelerating factor for creating branch_5x and
getting that show on the road.

Addressing something earlier in the thread, here are my thoughts about
why we don't do very many bugfix releases:

* Based on what I've seen of the release process, there's not a huge
difference in effort for a minor release compared to a bugfix release.
Unless there are extremely severe bugs to address, release manager
volunteers would rather put that effort into new and improved features.

* The current rapid pace of development, especially in SolrCloud, causes
so much drift in the codebase that it can be VERY difficult to backport
a critical fix.  Sometimes it's difficult because the fix is embedded in
changes for a whole new feature.  Backporting new features to a bugfix
release is usually avoided, because it can introduce NEW bugs.

Thanks,
Shawn

Re: More Maintenance Releases?

Posted by Erick Erickson <er...@gmail.com>.
Wondering if 4.7 is a "natural" point to do this.

See Uwe's announcement that as of Solr 4.8,
Solr/Lucene will _require_ Java 1.7 rather than
Java 1.6.

I know some organizations will not be able to
make this transition easily, thus I suspect we'll
see ongoing requests to "please back-port XXX
to Solr 4.7 since we can't use Java 1.7). Hmmm,
Solr 4.7, Java 1.7, coincidence? :).

Does it make any sense to think of essentially
freezing 4.7 except for bug fixes that we selectively
back-port?

Mostly random musings, but I thought I'd throw it
out there.

NOTE: I'm not volunteering to be the release
manager for this, that'd take someone who's
stuck on 1.6 IMO.

Best,
Erick

On Wed, Mar 12, 2014 at 6:52 PM, Furkan KAMACI <fu...@gmail.com> wrote:
> Hi;
>
> Here is the link:
> http://i740.photobucket.com/albums/xx43/kamaci/Solr_Releases_Furkan_KAMACI_zps8c0c196c.jpg
>
> Thanks;
> Furkan KAMACI
>
>
> 2014-03-12 21:21 GMT+02:00 Greg Walters <gr...@answers.com>:
>
>> Furkan,
>>
>> This list tends to eat attachments. Could you post it somewhere like imgur?
>>
>> Thanks,
>> Greg
>>
>> On Mar 12, 2014, at 2:19 PM, Furkan KAMACI <fu...@gmail.com> wrote:
>>
>> > Hi;
>> >
>> > I've attached the chart that I've prepared as I mentioned at e-mail.
>> >
>> > Thanks;
>> > Furkan KAMACI
>> >
>> >
>> > 2014-03-12 21:17 GMT+02:00 Furkan KAMACI <fu...@gmail.com>:
>> > Hi;
>> >
>> > I'm not a committer yet but I want to share my thoughts from a
>> perspective of a user. I've been using SolrCloud since 4.1.0 version of it.
>> I've read nearly all e-mails and I follow mail list too. Solr project has a
>> great development cycle and has a frequent release cycle. In fact, if you
>> compare it with some other Apache Projects it is has really nice commit
>> rates. I've prepared a chart that explains the release cycle of Solr since
>> 4.0 and attached it to this e-mail to make everything clear.
>> >
>> > When you check the chart that I prepared you will see that Solr has
>> followed that release cycle(for 4.x releases):
>> > If needed it has always had bugfix releases. So except for 4.0, 4.1.0
>> and 4.4.0 it had bug fix-releases (I do not include 4.7). However bug-fix
>> releases are applied once for each main release. I mean there is no 4.3.2
>> after 4.3.1 or 4.6.2 after 4.6.1
>> >
>> > When you use a project as like Solr you should catch up the current
>> release or current stable release (as like a bugfix release). I think
>> question should be that. If somebody finds a bug at a bugfix release what
>> will happen? Will be a 4.x.2 release or it will be resolved with 4.x+1.2?
>> >
>> > I also think that solution can be that: maintaining 4.x.1 and applying
>> changes to both for 4.x+1.0 and 4.x.2 So if anybody wants to use new
>> features (of course with recently bug fixes) and accept the risk of new
>> features user can use 4.x+1.0 otherwise a more stable version: 4.x.2
>> >
>> > This causes a new question. What will be the limit for "y" at 4.x.y? As
>> a perspective of a user who uses Solr and tests and checks its all versions
>> my thought is that: 2 (or 3) may be enough for that. Long term support is a
>> good idea (if you accept value of "y" as 2 or 3 it will be 4-6 months).
>> Solr is developing so fast and it has nearly good features that users
>> really need it.
>> >
>> > "If maintenance is not a problem" to apply bug-fixes to a release of
>> 4.x.2 and 4.x+1.0 having a "y" vale that is greater than "1" may be a
>> solution.
>> > If we just say that: "this release will be long term supported" -I think
>> that- people will want to use new releases after a time later because of
>> the new features nowadays. On the other hand if we release more than 1
>> bug-fix releases and if people do not need new features they will have a
>> more stable version of their current version and will be able to use it.
>> >
>> > Thanks;
>> > Furkan KAMACI
>> >
>> >
>> > 2014-03-12 18:34 GMT+02:00 Mark Miller <ma...@gmail.com>:
>> >
>> > +1 to the idea, I love bug fix releases (which is why I volunteered to
>> do the last couple).
>> >
>> > The main limiting factor is a volunteer to do it. Users requesting a
>> specific bug fix relese is probably a good way to prompt volunteers though.
>> >
>> > --
>> > Mark Miller
>> > about.me/markrmiller
>> >
>> > On March 12, 2014 at 9:14:50 AM, Doug Turnbull (
>> dturnbull@opensourceconnections.com) wrote:
>> >
>> > Hello Solr community,
>> >
>> > We have been using Solr to great effect at OpenSource Connections.
>> > Occasionally though, we'll hit a bug in say 4.5.1, that gets fixed in
>> > 4.6.0. Unfortunately, as 4.6.0 is a release sporting several new
>> features,
>> > there's invariably new bugs that get introduced. So while my bug in 4.5.1
>> > is fixed, a new bug related to new features in 4.6.0 means 4.6.0 might
>> be a
>> > showstopper.
>> >
>> > This is more a question for the PMC than anything (with comments from
>> > others welcome). Would it be possible to do more minor bug-fix releases?
>> I
>> > realize this could be a burden, so maybe it would be good to pick a
>> > version and decide this will be a "long term support" release. We will
>> > backport bug fixes and do several additional bug-fix releases for 4-6
>> > months? Then we'd pick another version to be a "long term support"
>> release?
>> >
>> > This would help with the overall stability of Solr and help in the
>> decision
>> > about how/when to upgrade Solr.
>> >
>> > Cheers,
>> > --
>> > Doug Turnbull
>> > Search & Big Data Architect
>> > OpenSource Connections <http://o19s.com>
>> >
>> >
>>
>>

Re: More Maintenance Releases?

Posted by Furkan KAMACI <fu...@gmail.com>.
Hi;

Here is the link:
http://i740.photobucket.com/albums/xx43/kamaci/Solr_Releases_Furkan_KAMACI_zps8c0c196c.jpg

Thanks;
Furkan KAMACI


2014-03-12 21:21 GMT+02:00 Greg Walters <gr...@answers.com>:

> Furkan,
>
> This list tends to eat attachments. Could you post it somewhere like imgur?
>
> Thanks,
> Greg
>
> On Mar 12, 2014, at 2:19 PM, Furkan KAMACI <fu...@gmail.com> wrote:
>
> > Hi;
> >
> > I've attached the chart that I've prepared as I mentioned at e-mail.
> >
> > Thanks;
> > Furkan KAMACI
> >
> >
> > 2014-03-12 21:17 GMT+02:00 Furkan KAMACI <fu...@gmail.com>:
> > Hi;
> >
> > I'm not a committer yet but I want to share my thoughts from a
> perspective of a user. I've been using SolrCloud since 4.1.0 version of it.
> I've read nearly all e-mails and I follow mail list too. Solr project has a
> great development cycle and has a frequent release cycle. In fact, if you
> compare it with some other Apache Projects it is has really nice commit
> rates. I've prepared a chart that explains the release cycle of Solr since
> 4.0 and attached it to this e-mail to make everything clear.
> >
> > When you check the chart that I prepared you will see that Solr has
> followed that release cycle(for 4.x releases):
> > If needed it has always had bugfix releases. So except for 4.0, 4.1.0
> and 4.4.0 it had bug fix-releases (I do not include 4.7). However bug-fix
> releases are applied once for each main release. I mean there is no 4.3.2
> after 4.3.1 or 4.6.2 after 4.6.1
> >
> > When you use a project as like Solr you should catch up the current
> release or current stable release (as like a bugfix release). I think
> question should be that. If somebody finds a bug at a bugfix release what
> will happen? Will be a 4.x.2 release or it will be resolved with 4.x+1.2?
> >
> > I also think that solution can be that: maintaining 4.x.1 and applying
> changes to both for 4.x+1.0 and 4.x.2 So if anybody wants to use new
> features (of course with recently bug fixes) and accept the risk of new
> features user can use 4.x+1.0 otherwise a more stable version: 4.x.2
> >
> > This causes a new question. What will be the limit for "y" at 4.x.y? As
> a perspective of a user who uses Solr and tests and checks its all versions
> my thought is that: 2 (or 3) may be enough for that. Long term support is a
> good idea (if you accept value of "y" as 2 or 3 it will be 4-6 months).
> Solr is developing so fast and it has nearly good features that users
> really need it.
> >
> > "If maintenance is not a problem" to apply bug-fixes to a release of
> 4.x.2 and 4.x+1.0 having a "y" vale that is greater than "1" may be a
> solution.
> > If we just say that: "this release will be long term supported" -I think
> that- people will want to use new releases after a time later because of
> the new features nowadays. On the other hand if we release more than 1
> bug-fix releases and if people do not need new features they will have a
> more stable version of their current version and will be able to use it.
> >
> > Thanks;
> > Furkan KAMACI
> >
> >
> > 2014-03-12 18:34 GMT+02:00 Mark Miller <ma...@gmail.com>:
> >
> > +1 to the idea, I love bug fix releases (which is why I volunteered to
> do the last couple).
> >
> > The main limiting factor is a volunteer to do it. Users requesting a
> specific bug fix relese is probably a good way to prompt volunteers though.
> >
> > --
> > Mark Miller
> > about.me/markrmiller
> >
> > On March 12, 2014 at 9:14:50 AM, Doug Turnbull (
> dturnbull@opensourceconnections.com) wrote:
> >
> > Hello Solr community,
> >
> > We have been using Solr to great effect at OpenSource Connections.
> > Occasionally though, we'll hit a bug in say 4.5.1, that gets fixed in
> > 4.6.0. Unfortunately, as 4.6.0 is a release sporting several new
> features,
> > there's invariably new bugs that get introduced. So while my bug in 4.5.1
> > is fixed, a new bug related to new features in 4.6.0 means 4.6.0 might
> be a
> > showstopper.
> >
> > This is more a question for the PMC than anything (with comments from
> > others welcome). Would it be possible to do more minor bug-fix releases?
> I
> > realize this could be a burden, so maybe it would be good to pick a
> > version and decide this will be a "long term support" release. We will
> > backport bug fixes and do several additional bug-fix releases for 4-6
> > months? Then we'd pick another version to be a "long term support"
> release?
> >
> > This would help with the overall stability of Solr and help in the
> decision
> > about how/when to upgrade Solr.
> >
> > Cheers,
> > --
> > Doug Turnbull
> > Search & Big Data Architect
> > OpenSource Connections <http://o19s.com>
> >
> >
>
>

Re: More Maintenance Releases?

Posted by Greg Walters <gr...@answers.com>.
Furkan,

This list tends to eat attachments. Could you post it somewhere like imgur?

Thanks,
Greg

On Mar 12, 2014, at 2:19 PM, Furkan KAMACI <fu...@gmail.com> wrote:

> Hi;
> 
> I've attached the chart that I've prepared as I mentioned at e-mail.
> 
> Thanks;
> Furkan KAMACI
> 
> 
> 2014-03-12 21:17 GMT+02:00 Furkan KAMACI <fu...@gmail.com>:
> Hi;
> 
> I'm not a committer yet but I want to share my thoughts from a perspective of a user. I've been using SolrCloud since 4.1.0 version of it. I've read nearly all e-mails and I follow mail list too. Solr project has a great development cycle and has a frequent release cycle. In fact, if you compare it with some other Apache Projects it is has really nice commit rates. I've prepared a chart that explains the release cycle of Solr since 4.0 and attached it to this e-mail to make everything clear.
> 
> When you check the chart that I prepared you will see that Solr has followed that release cycle(for 4.x releases): 
> If needed it has always had bugfix releases. So except for 4.0, 4.1.0 and 4.4.0 it had bug fix-releases (I do not include 4.7). However bug-fix releases are applied once for each main release. I mean there is no 4.3.2 after 4.3.1 or 4.6.2 after 4.6.1
> 
> When you use a project as like Solr you should catch up the current release or current stable release (as like a bugfix release). I think question should be that. If somebody finds a bug at a bugfix release what will happen? Will be a 4.x.2 release or it will be resolved with 4.x+1.2? 
> 
> I also think that solution can be that: maintaining 4.x.1 and applying changes to both for 4.x+1.0 and 4.x.2 So if anybody wants to use new features (of course with recently bug fixes) and accept the risk of new features user can use 4.x+1.0 otherwise a more stable version: 4.x.2
> 
> This causes a new question. What will be the limit for "y" at 4.x.y? As a perspective of a user who uses Solr and tests and checks its all versions my thought is that: 2 (or 3) may be enough for that. Long term support is a good idea (if you accept value of "y" as 2 or 3 it will be 4-6 months). Solr is developing so fast and it has nearly good features that users really need it. 
> 
> "If maintenance is not a problem" to apply bug-fixes to a release of 4.x.2 and 4.x+1.0 having a "y" vale that is greater than "1" may be a solution. 
> If we just say that: "this release will be long term supported" -I think that- people will want to use new releases after a time later because of the new features nowadays. On the other hand if we release more than 1 bug-fix releases and if people do not need new features they will have a more stable version of their current version and will be able to use it.
> 
> Thanks;
> Furkan KAMACI
> 
> 
> 2014-03-12 18:34 GMT+02:00 Mark Miller <ma...@gmail.com>:
> 
> +1 to the idea, I love bug fix releases (which is why I volunteered to do the last couple).
> 
> The main limiting factor is a volunteer to do it. Users requesting a specific bug fix relese is probably a good way to prompt volunteers though.
> 
> -- 
> Mark Miller
> about.me/markrmiller
> 
> On March 12, 2014 at 9:14:50 AM, Doug Turnbull (dturnbull@opensourceconnections.com) wrote:
> 
> Hello Solr community,
> 
> We have been using Solr to great effect at OpenSource Connections.
> Occasionally though, we'll hit a bug in say 4.5.1, that gets fixed in
> 4.6.0. Unfortunately, as 4.6.0 is a release sporting several new features,
> there's invariably new bugs that get introduced. So while my bug in 4.5.1
> is fixed, a new bug related to new features in 4.6.0 means 4.6.0 might be a
> showstopper.
> 
> This is more a question for the PMC than anything (with comments from
> others welcome). Would it be possible to do more minor bug-fix releases? I
> realize this could be a burden, so maybe it would be good to pick a
> version and decide this will be a "long term support" release. We will
> backport bug fixes and do several additional bug-fix releases for 4-6
> months? Then we'd pick another version to be a "long term support" release?
> 
> This would help with the overall stability of Solr and help in the decision
> about how/when to upgrade Solr.
> 
> Cheers,
> --
> Doug Turnbull
> Search & Big Data Architect
> OpenSource Connections <http://o19s.com>
> 
>

Re: More Maintenance Releases?

Posted by Furkan KAMACI <fu...@gmail.com>.
Hi;

I've attached the chart that I've prepared as I mentioned at e-mail.

Thanks;
Furkan KAMACI


2014-03-12 21:17 GMT+02:00 Furkan KAMACI <fu...@gmail.com>:

> Hi;
>
> I'm not a committer yet but I want to share my thoughts from a perspective
> of a user. I've been using SolrCloud since 4.1.0 version of it. I've read
> nearly all e-mails and I follow mail list too. Solr project has a great
> development cycle and has a frequent release cycle. In fact, if you compare
> it with some other Apache Projects it is has really nice commit rates. I've
> prepared a chart that explains the release cycle of Solr since 4.0 and
> attached it to this e-mail to make everything clear.
>
> When you check the chart that I prepared you will see that Solr has
> followed that release cycle(for 4.x releases):
> If needed it has always had bugfix releases. So except for 4.0, 4.1.0 and
> 4.4.0 it had bug fix-releases (I do not include 4.7). However bug-fix
> releases are applied once for each main release. I mean there is no 4.3.2
> after 4.3.1 or 4.6.2 after 4.6.1
>
> When you use a project as like Solr you should catch up the current
> release or current stable release (as like a bugfix release). I think
> question should be that. If somebody finds a bug at a bugfix release what
> will happen? Will be a 4.x.2 release or it will be resolved with 4.x+1.2?
>
> I also think that solution can be that: maintaining 4.x.1 and applying
> changes to both for 4.x+1.0 and 4.x.2 So if anybody wants to use new
> features (of course with recently bug fixes) and accept the risk of new
> features user can use 4.x+1.0 otherwise a more stable version: 4.x.2
>
> This causes a new question. What will be the limit for "*y*" at 4.x.y? As
> a perspective of a user who uses Solr and tests and checks its all versions
> my thought is that: 2 (or 3) may be enough for that. Long term support is a
> good idea (if you accept value of "*y*" as 2 or 3 it will be 4-6 months).
> Solr is developing so fast and it has nearly good features that users
> really need it.
>
> "If maintenance is not a problem" to apply bug-fixes to a release of 4.x.2
> and 4.x+1.0 having a "*y*" vale that is greater than "1" may be a
> solution.
> If we just say that: "this release will be long term supported" -I think
> that- people will want to use new releases after a time later because of
> the new features nowadays. On the other hand if we release more than 1
> bug-fix releases and if people do not need new features they will have a
> more stable version of their current version and will be able to use it.
>
> Thanks;
> Furkan KAMACI
>
>
> 2014-03-12 18:34 GMT+02:00 Mark Miller <ma...@gmail.com>:
>
> +1 to the idea, I love bug fix releases (which is why I volunteered to do
>> the last couple).
>>
>> The main limiting factor is a volunteer to do it. Users requesting a
>> specific bug fix relese is probably a good way to prompt volunteers though.
>>
>> --
>> Mark Miller
>> about.me/markrmiller
>>
>> On March 12, 2014 at 9:14:50 AM, Doug Turnbull (
>> dturnbull@opensourceconnections.com) wrote:
>>
>> Hello Solr community,
>>
>> We have been using Solr to great effect at OpenSource Connections.
>> Occasionally though, we'll hit a bug in say 4.5.1, that gets fixed in
>> 4.6.0. Unfortunately, as 4.6.0 is a release sporting several new features,
>> there's invariably new bugs that get introduced. So while my bug in 4.5.1
>> is fixed, a new bug related to new features in 4.6.0 means 4.6.0 might be
>> a
>> showstopper.
>>
>> This is more a question for the PMC than anything (with comments from
>> others welcome). Would it be possible to do more minor bug-fix releases? I
>> realize this could be a burden, so maybe it would be good to pick a
>> version and decide this will be a "long term support" release. We will
>> backport bug fixes and do several additional bug-fix releases for 4-6
>> months? Then we'd pick another version to be a "long term support"
>> release?
>>
>> This would help with the overall stability of Solr and help in the
>> decision
>> about how/when to upgrade Solr.
>>
>> Cheers,
>> --
>> Doug Turnbull
>> Search & Big Data Architect
>> OpenSource Connections <http://o19s.com>
>>
>
>

Re: More Maintenance Releases?

Posted by Furkan KAMACI <fu...@gmail.com>.
Hi;

I'm not a committer yet but I want to share my thoughts from a perspective
of a user. I've been using SolrCloud since 4.1.0 version of it. I've read
nearly all e-mails and I follow mail list too. Solr project has a great
development cycle and has a frequent release cycle. In fact, if you compare
it with some other Apache Projects it is has really nice commit rates. I've
prepared a chart that explains the release cycle of Solr since 4.0 and
attached it to this e-mail to make everything clear.

When you check the chart that I prepared you will see that Solr has
followed that release cycle(for 4.x releases):
If needed it has always had bugfix releases. So except for 4.0, 4.1.0 and
4.4.0 it had bug fix-releases (I do not include 4.7). However bug-fix
releases are applied once for each main release. I mean there is no 4.3.2
after 4.3.1 or 4.6.2 after 4.6.1

When you use a project as like Solr you should catch up the current release
or current stable release (as like a bugfix release). I think question
should be that. If somebody finds a bug at a bugfix release what will
happen? Will be a 4.x.2 release or it will be resolved with 4.x+1.2?

I also think that solution can be that: maintaining 4.x.1 and applying
changes to both for 4.x+1.0 and 4.x.2 So if anybody wants to use new
features (of course with recently bug fixes) and accept the risk of new
features user can use 4.x+1.0 otherwise a more stable version: 4.x.2

This causes a new question. What will be the limit for "*y*" at 4.x.y? As a
perspective of a user who uses Solr and tests and checks its all versions
my thought is that: 2 (or 3) may be enough for that. Long term support is a
good idea (if you accept value of "*y*" as 2 or 3 it will be 4-6 months).
Solr is developing so fast and it has nearly good features that users
really need it.

"If maintenance is not a problem" to apply bug-fixes to a release of 4.x.2
and 4.x+1.0 having a "*y*" vale that is greater than "1" may be a solution.
If we just say that: "this release will be long term supported" -I think
that- people will want to use new releases after a time later because of
the new features nowadays. On the other hand if we release more than 1
bug-fix releases and if people do not need new features they will have a
more stable version of their current version and will be able to use it.

Thanks;
Furkan KAMACI


2014-03-12 18:34 GMT+02:00 Mark Miller <ma...@gmail.com>:

> +1 to the idea, I love bug fix releases (which is why I volunteered to do
> the last couple).
>
> The main limiting factor is a volunteer to do it. Users requesting a
> specific bug fix relese is probably a good way to prompt volunteers though.
>
> --
> Mark Miller
> about.me/markrmiller
>
> On March 12, 2014 at 9:14:50 AM, Doug Turnbull (
> dturnbull@opensourceconnections.com) wrote:
>
> Hello Solr community,
>
> We have been using Solr to great effect at OpenSource Connections.
> Occasionally though, we'll hit a bug in say 4.5.1, that gets fixed in
> 4.6.0. Unfortunately, as 4.6.0 is a release sporting several new features,
> there's invariably new bugs that get introduced. So while my bug in 4.5.1
> is fixed, a new bug related to new features in 4.6.0 means 4.6.0 might be a
> showstopper.
>
> This is more a question for the PMC than anything (with comments from
> others welcome). Would it be possible to do more minor bug-fix releases? I
> realize this could be a burden, so maybe it would be good to pick a
> version and decide this will be a "long term support" release. We will
> backport bug fixes and do several additional bug-fix releases for 4-6
> months? Then we'd pick another version to be a "long term support" release?
>
> This would help with the overall stability of Solr and help in the decision
> about how/when to upgrade Solr.
>
> Cheers,
> --
> Doug Turnbull
> Search & Big Data Architect
> OpenSource Connections <http://o19s.com>
>

Re: More Maintenance Releases?

Posted by Mark Miller <ma...@gmail.com>.
+1 to the idea, I love bug fix releases (which is why I volunteered to do the last couple).

The main limiting factor is a volunteer to do it. Users requesting a specific bug fix relese is probably a good way to prompt volunteers though.

-- 
Mark Miller
about.me/markrmiller

On March 12, 2014 at 9:14:50 AM, Doug Turnbull (dturnbull@opensourceconnections.com) wrote:

Hello Solr community,  

We have been using Solr to great effect at OpenSource Connections.  
Occasionally though, we'll hit a bug in say 4.5.1, that gets fixed in  
4.6.0. Unfortunately, as 4.6.0 is a release sporting several new features,  
there's invariably new bugs that get introduced. So while my bug in 4.5.1  
is fixed, a new bug related to new features in 4.6.0 means 4.6.0 might be a  
showstopper.  

This is more a question for the PMC than anything (with comments from  
others welcome). Would it be possible to do more minor bug-fix releases? I  
realize this could be a burden, so maybe it would be good to pick a  
version and decide this will be a "long term support" release. We will  
backport bug fixes and do several additional bug-fix releases for 4-6  
months? Then we'd pick another version to be a "long term support" release?  

This would help with the overall stability of Solr and help in the decision  
about how/when to upgrade Solr.  

Cheers,  
--  
Doug Turnbull  
Search & Big Data Architect  
OpenSource Connections <http://o19s.com>