I agree with the approach Jan voiced - that at least some of these features should appear in 9.0 as deprecated to give users more time.
That said, maybe discussing what to do around these features should be its own thread or should be taken back to some of the specific jiras where there's already been some discussion (e.g. SOLR-14616). It just seems likely to hijack this thread away from other discussions (how to manage/handle our new Roadmap page). On Wed, Aug 12, 2020 at 9:35 AM Ishan Chattopadhyaya <[email protected]> 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 support the DIH, autoscaling and CDCR going away in 9.0, rest of the things > can just move into first party packages and continue to be part of the > distribution. Does that make sense, Jan? > > On Wed, Aug 12, 2020 at 1:36 PM Jan Høydahl <[email protected]> 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 <[email protected]>: >> >> 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 <[email protected]> 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 <[email protected]> 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 >>>> <[email protected]> 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 <[email protected]> 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 <[email protected]>: >>>>>> >>>>>> >>>>>> > >>>>>> >>>>>> >>>>>> > 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 <[email protected]> >>>>>> > 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 <[email protected]>: >>>>>> >>>>>> >>>>>> >> >>>>>> >>>>>> >>>>>> >> >>>>>> >>>>>> >>>>>> >>> 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: [email protected] >>>>>> >>>>>> >>>>>> > For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> >>>>>> >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> http://www.needhamsoftware.com (work) >>>> http://www.the111shift.com (play) >>>> >>>> >> >> >> -- >> http://www.needhamsoftware.com (work) >> http://www.the111shift.com (play) >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
