I'd like to have until June 2nd to finish up tickets for 6.7. That would give use a little leeway to get 6.7 released before starting the 7.0 release process around June 10th.
Joel Bernstein http://joelsolr.blogspot.com/ On Wed, May 24, 2017 at 7:13 PM, Anshum Gupta <ans...@anshumgupta.net> wrote: > Do we have an idea on what/when are we looking at w.r.t a 6.7 release? > > Bug fixes that follow are totally ok, and should be released but this is > more about, when do we stop adding 'new features' to the 6x branch, even if > that involves back-porting. > > Assuming that the 6.7 release would be some time in June, that would still > be before the first 7x release happens, which to me is ok. Anything more, > and it starts getting confusing to end-users. If am not opposing more 6x > releases but just trying to keep things simple to manage for both, > end-users, and contributors. > > -Anshum > > > On Wed, May 24, 2017 at 12:45 AM Adrien Grand <jpou...@gmail.com> wrote: > >> Le mar. 23 mai 2017 à 20:01, Shawn Heisey <apa...@elyograg.org> a écrit : >> >>> What is our plan for legacy numerics in Solr 7.0? Looking at the >>> example configs in branch_6x, I see that they have been partially >>> converted to the point field types, but not fully. The _version_ field >>> and many dynamic fields are still using Trie types. >>> >>> If legacy numerics disappear from Solr 7.0 (since normal deprecation >>> rules indicate they will be gone from Lucene 7.0), very few 6.x users >>> will be able to upgrade to 7.0 without redesigning and completely >>> rebuilding their indexes. >>> >> >> We said before that we could move it to the solr sub-folder so that Solr >> can support them for one additional major release (it can be done on top of >> Lucene, doesn't need to be supported in Lucene directly). However it is >> probably important to do whatever needs to be done now (ie. before 7.0 is >> released) so that the removal of legacy numerics will be seamless for users >> in 8.0. For instance maybe Solr should disallow the addition of legacy >> numerics to the schema of indices that are created on 7.x? Or alternatively >> implicitly upgrade those fields to points (for 7.x indices only, otherwise >> it would break old indices) if you think it provides a better user >> experience. >> >> Regarding Adrien's concern, if the index format doesn't change and >>> existing analysis components don't do anything radically different, it >>> should be pretty safe to fix minor problems and backport self-contained >>> features in 6.x releases after 7.0 hits. >>> >> >> To me the best trade-off is to stop doing 6.x minor releases once 7.0 is >> out. It is simple and safe. And encouraging users to upgrade if they want >> to take advantage of new features might not be a bad thing. If we really >> really really want to keep releasing features in 6.x, I think we have two >> options: add forward-compatibility tests to make sure that all 7.x releases >> can read indices created by the new 6.x release, or decouple the release >> cycles of Lucene and Solr so that Solr can keep adding features on 6.x by >> staying on the exact same Lucene version. I understand the likeliness that >> we break forward compatibility is not high, but it can happen in unexpected >> ways, and if it happens it would be terrible. >> >
