> With 9x having java 11 and gradle migrations on the dev side, and about to have > a significant round of deprecations/removals and migrations to plugin for things > such as CDCR, DIH etc (see https://issues.apache.org/jira/browse/SOLR-13442 > and https://issues.apache.org/jira/browse/SOLR-14022) some of which may(?) > need a replacement (i.e. CDCR?) or ways ot easily re-enable (i.e. streaming) > before 9x is able to be released. Plus there's been talk of a revamped UI...
I think we should avoid large code drop-ins at all costs. No new CDCR or UI code should be part of Solr codebase. Any big, new feature should be built as packages. On Fri, Jul 3, 2020 at 1:49 AM David Smiley <dsmi...@apache.org> wrote: > No more JIRA fields please; "Fix Version" is adequate. You can edit an > issue after creating it to set the "Fix version" to "master (9.0)"; the > issue doesn't have to be resolved yet. I recently had ASF change JIRA so > that this field is not editable on creation of the issue because our > contributors don't know any better than to put something inappropriate > there. But the edit screen works. > > I think Lucene might release v9 without Solr if Solr is going to drag its > feet for too long. Wearing my Lucene hat (er... well shirt), I support > that within reason. > > Agreed on Confluence. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > > On Thu, Jul 2, 2020 at 2:30 PM Gus Heck <gus.h...@gmail.com> wrote: > >> Looking at >> https://issues.apache.org/jira/projects/SOLR?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased >> maybe >> this is as simple as having one more field on our issues... Currently fix >> version denotes when something got fixed, perhaps a "target version" field >> could indicate when we want to fix it by. Then we just need a tag in jira >> and perhaps a branch. >> >> Alternately (or maybe additionally) we could make a "board" if that's >> easier to monitor. >> >> On Thu, Jul 2, 2020 at 2:02 PM Gus Heck <gus.h...@gmail.com> wrote: >> >>> Jira typically has features for designating what's in a release.... >>> >>> On Thu, Jul 2, 2020 at 1:55 PM Erick Erickson <erickerick...@gmail.com> >>> wrote: >>> >>>> 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. >>>> >>>> That said, yeah, I do think it’s time to start getting a handle on 9.0. >>>> Pulling Ant out of the build system is another possibility. >>>> >>>> Solr as a TLP? Or is that Solr 10? Or does it even have to be as of a >>>> major release? >>>> >>>> Sound like a Wiki page or some such to me… >>>> >>>> Erick >>>> >>>> > On Jul 2, 2020, at 1:07 PM, Andrzej Białecki <a...@getopt.org> wrote: >>>> > >>>> > Autoscaling is another big item, but I think we have to put it into >>>> 9x, it’s a critical (and critically broken) functionality. We’re making >>>> some progress with Ilan and Noble so I’m cautiously optimistic. >>>> > >>>> >> On 2 Jul 2020, at 18:58, Gus Heck <gus.h...@gmail.com> wrote: >>>> >> >>>> >> Should we have one? >>>> >> >>>> >> With 9x having java 11 and gradle migrations on the dev side, and >>>> about to have a significant round of deprecations/removals and migrations >>>> to plugin for things such as CDCR, DIH etc (see >>>> https://issues.apache.org/jira/browse/SOLR-13442 and >>>> https://issues.apache.org/jira/browse/SOLR-14022) some of which may(?) >>>> need a replacement (i.e. CDCR?) or ways ot easily re-enable (i.e. >>>> streaming) before 9x is able to be released. Plus there's been talk of a >>>> revamped UI... >>>> >> >>>> >> I'm worried that there is a danger that 9x will continue to diverge >>>> and pick up major changes, but always have something big in progress and >>>> never be able to release. >>>> >> >>>> >> Perhaps we should attempt to put a box around the things that need >>>> to happen for 9x, and begin targeting any larger projects that come up at >>>> 10x? Among other things the gradle work probably can't be complete until >>>> someone has gone through a release using it. (I don't think we build the >>>> tarballs in gradle yet for example, unless that got added recently) >>>> >> >>>> >> -Gus >>>> >> >>>> >> -- >>>> >> 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 >>>> >>>> >>> >>> -- >>> http://www.needhamsoftware.com (work) >>> http://www.the111shift.com (play) >>> >> >> >> -- >> http://www.needhamsoftware.com (work) >> http://www.the111shift.com (play) >> >
