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. >
