lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Furkan KAMACI <>
Subject Re: More Maintenance Releases?
Date Wed, 12 Mar 2014 19:19:24 GMT

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


2014-03-12 21:17 GMT+02:00 Furkan KAMACI <>:

> 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 <>:
> +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
>> On March 12, 2014 at 9:14:50 AM, Doug Turnbull (
>> 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 <>

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message