> > It has been proposed on the list to NOT rip out all deprecations in 9.0, > but allow users to upgrade to 9.0 with e.g. SolrCell still available, and > then have yet some time to change their processes to adapt to the new way > of doing stuff. I like that proposal. Sure, 9.0 will remove lots of > deprecated code, but I think it is a mistake to do all of the proposed > removals at once. We can spread removals out in 9.x releases, after users > have had a few releases with a choice between old and new and the new > alternative is solid. >
I find it highly depressing that we can't, *in a major release*, manage to get rid of our deprecations -- particularly for code that has a new home and is packaged in a form that is trivial to install (thanks to our new awesome package manager). I'm sympathetic to waiting to delete until *after* there is an actual package ready at that time (rather than just the promise of one). Also, users generally are cautious on performing a major version upgrade. There's time. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Aug 12, 2020 at 4:06 AM Jan Høydahl <jan....@cominvent.com> wrote: > I edited the page to introduce the (super important) Solr TLP split into > the roadmap. > Also added a rough timeframe and a «major theme» for each release above > the issue table. > I added 8.8 and 9.1 as I think it is important to track what gets done > just before 9.0 and what can be deferred to after 9.0. > > It has been proposed on the list to NOT rip out all deprecations in 9.0, > but allow users to upgrade to 9.0 with e.g. SolrCell still available, and > then have yet some time to change their processes to adapt to the new way > of doing stuff. I like that proposal. Sure, 9.0 will remove lots of > deprecated code, but I think it is a mistake to do all of the proposed > removals at once. We can spread removals out in 9.x releases, after users > have had a few releases with a choice between old and new and the new > alternative is solid. > > Thanks Gus for taking ownership and suggesting a process! Feel free to > rework what I edited into a structure you see more fit. > > Jan > > 11. aug. 2020 kl. 18:51 skrev Gus Heck <gus.h...@gmail.com>: > > I was thinking that level of detail is in the Jira... I don't see any > reason for things to disappear (in fact rejected should go in a rejected > list for future reference.) > > On Tue, Aug 11, 2020 at 12:04 PM Ilan Ginzburg <ilans...@gmail.com> wrote: > >> Maybe also add “in progress”? So items do not disappear suddenly from the >> page when work really starts on them? >> >> On Tue 11 Aug 2020 at 17:15, Gus Heck <gus.h...@gmail.com> wrote: >> >>> Cool, since I brought it up, I can volunteer to help manage the page. We >>> should get jira issue links in there wherever possible. Do we want to build >>> an initial list and have some sort of Proposed/Planned workflow so readers >>> can have confidence (or appropriate lack of confidence) in what they see >>> there? voting on things seems like too much but maybe folks who care watch >>> the page, and if something is on there for a week without objection it can >>> be called accepted? If a discussion starts here it can be marked >>> "Considering" so... something like this: >>> >>> 4 states: Proposed, Considering, Planned, Rejected >>> >>> Workflow like this: >>> Proposed -------(no objection 1 wk) --> Planned >>> Proposed -------(discussion)----------> Considering >>> Considering ----(agreement) ----------> Planned >>> Considering ----(deferred) -----------> Proposed (later release) >>> Considering ----(unsuitable) ---------> Rejected >>> Considering ----(promoted) -----------> Proposed (earlier release) >>> Planned --------(difficulty found) ---> Considering >>> >>> Anything in "Considering" should have an active dev list thread, and if >>> it didn't happen on the list it didn't happen :). Any of that (or >>> differences of opinion during Considering) can be overridden by a formal >>> vote of course >>> >>> -Gus >>> >>> >>> >>> >>> On Tue, Aug 11, 2020 at 10:29 AM Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com> wrote: >>> >>>> I've created a placeholder document here: >>>> https://cwiki.apache.org/confluence/display/SOLR/Roadmap >>>> Let us put in all our items there. >>>> >>>> On Tue, Aug 11, 2020 at 4:45 PM Jan Høydahl <jan....@cominvent.com> >>>> wrote: >>>> >>>>> Let’s revive this email thread about Roadmap. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> With so many large initiatives going on, and the TLP split also, I >>>>> think it makes perfect sense with a Roadmap. >>>>> >>>>> >>>>> I know we’re not used to that kind of thing - we tend to just let >>>>> things play out as it happens to land in various releases, but this time >>>>> is >>>>> special, and I think we’d benefit from more coordination. I don’t know how >>>>> to enforce such coordination though, other than appealing to all >>>>> committers >>>>> to endorse the roadmap and respect it when they merge things. We may not >>>>> be >>>>> able to set a release date for 9.0 right now, but we may be able to define >>>>> preconditions and scope certain features to 9.0 or 9.1 rather than 8.7 or >>>>> 8.8 - that kind of coarse-grained decisions. We also may need a person >>>>> that >>>>> «owns» the Roadmap confluence page and actively promotes it, tries to keep >>>>> it up to date and reminds the rest of us about its existence. A roadmap >>>>> must NOT be a brake slowing us down, but a tool helping us avoid silly >>>>> mistakes. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Jan >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> > 5. jul. 2020 kl. 02:39 skrev Noble Paul <noble.p...@gmail.com>: >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > I think the logical thing to do today is completely rip out all >>>>> >>>>> >>>>> > autoscaling code as it exists today. >>>>> >>>>> >>>>> > Let's deprecate that in 8.7 and build something for >>>>> "assign-strategy". >>>>> >>>>> >>>>> > Austoscaling , if required, should not be a part of Solr >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > On Fri, Jul 3, 2020 at 5:48 PM Jan Høydahl <jan....@cominvent.com> >>>>> wrote: >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> +1 >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> Why don’t we make a Roadmap wiki page as Cassandra suggests, and >>>>> indicate what major things needs to happen when. >>>>> >>>>> >>>>> >> Perhaps if we can get the Solr TLP and git-split ball rolling as a >>>>> pre-9.0 task, then perhaps 8.8 could be the last joint release (6.6, 7.7, >>>>> 8.8 hehe)? >>>>> >>>>> >>>>> >> That would enable Lucene to ship 9.0 without waiting for a ton of >>>>> alpha-quality Solr features, and Solr could have its own Roadmap wiki. >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> Jan >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> 3. jul. 2020 kl. 09:19 skrev Dawid Weiss <dawid.we...@gmail.com>: >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >>> I totally expect some things to bubble up when we try to release >>>>> with Gradle, the tarball being one. I don’t think that’s a very big issue, >>>>> but if you have lots of “not very big” issues they do add up. >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> Adding a tarball is literally 3-5 lines of code (you add a task >>>>> that builds a tarball or a zip file from the outputs of solr/packaging >>>>> toDir task)... The bigger issue with gradle is that somebody has to step >>>>> up >>>>> and try to identify any other issues and/or missing bits when trying to do >>>>> a full release cycle. >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> D. >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> >> >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > -- >>>>> >>>>> >>>>> > ----------------------------------------------------- >>>>> >>>>> >>>>> > Noble Paul >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> > --------------------------------------------------------------------- >>>>> >>>>> >>>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>> >>>>> >>>>> > For additional commands, e-mail: dev-h...@lucene.apache.org >>>>> >>>>> >>>>> > >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> >>>>> >>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>>> >>>>> >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> http://www.needhamsoftware.com (work) >>> http://www.the111shift.com (play) >>> >>> >>> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > > >
