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 <furkankam...@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 <greg.walt...@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 <furkankam...@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 <furkankam...@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 <markrmil...@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 ( >> dturnb...@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> >> > >> > >> >>
