> 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 not sure why you think "we can't". I can't even remember a single committer standing in the way of removing those *that already have a package*. However, there's a backlash against removing CDCR even though there is no one volunteering to support it (as a package) and it is clearly broken, which is what totally puzzles me. https://issues.apache.org/jira/browse/SOLR-14616 On Fri, Aug 28, 2020 at 4:19 AM Alexandre Rafalovitch <arafa...@gmail.com> wrote: > 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 > >
