Well, I have created SOLR-14783 (Remove DIH from 9.0) and am busily learning magic gradle commands to make that happen without leaving behind random crumbs. Once that lands, I will do Jira search on all DIH still-open tasks after that and close them pointing to the said Jira.
So, I guess somebody better -1 the Jira if they really want that one to stay until ... ? And then read very carefully through SIP-10 of which, this is just a first step. In general, maybe we can manage to do so many new features and cleanup in 9 that will make Solr TLP look like a great Big Bang moment... And it will probably take a little longer to achieve that, so the - effective - deprecation schedule would still be ok. Regards, Alex. On Thu, 27 Aug 2020 at 18:35, 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
