IMO, it’s super-awkward to preserve something for 9.0 then remove it for 9.1. I understand the tendency to say “deprecating it in 8.7 then removing it in the next release is too fast”, but that strikes me as even worse than taking it out of 9.0.
> On Aug 27, 2020, at 6:35 PM, David Smiley <dsmi...@apache.org> wrote: > > 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) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
