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
