IIUC, reference_impl is the branch where the changes are stable. *_dev is the branch where active development is going on. Once changes are baked in there, they are promoted to reference_impl. We want to release from reference_impl.
On Mon, 5 Oct, 2020, 6:16 pm Erick Erickson, <[email protected]> wrote: > Uwe: > > I think it’s reference_impl_dev... > > > On Oct 4, 2020, at 6:00 PM, Uwe Schindler <[email protected]> wrote: > > > > Hi, > > I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins > (Linux, Windows, MacOS). > > > > I used branch (“reference_impl”). Is this correct, because it’s about a > month old? > > There’s also a much newer “reference_impl_dev” branch. Which one is > correct? > > > > I will go sleeping now, sorry for failure mails during the night. Builds > seem to fail, but it’s too late to do anything against it. > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: [email protected] > > > > From: Ishan Chattopadhyaya <[email protected]> > > Sent: Sunday, October 4, 2020 6:32 AM > > To: Uwe Schindler <[email protected]> > > Cc: Lucene Dev <[email protected]> > > Subject: Re: Solr Alpha (EA) release of Reference Branch > > > > Yes Uwe, it is ready for Jenkins testing. The Solr tests should run very > fast now. > > > > As for naming, our package manager in Solr will break if we don't > specify a major and a minor version. There's a concept of version > constraints for packages that need to compare against Solr version. I think > release process will also be much simpler if we have a major and minor > version. We have done a similar release in the past, 4.0.0-beta iirc. > > > > Why I favour 10.0-alpha or something like that is because users would > clearly know it is something that isn't coming right now (and hence very > early access), and it is logically a major version change (that comes after > 8x). With calling it 10x instead of 9x, we have the scope of abandoning the > effort as a whole if the early access releases have some serious problem or > we decide to take some other release strategy later. > > > > If the 10.0-alpha succeeds, we can always fold the changes back into a > 9.1 or go from 9.0 straight to 10.0, depending on what we decide later. > Alternatively, if the release looks good and 9.0 hasn't released yet, we > can fold those changes back to master, and either (a) release everything > normally as 9.0, or (b) call master as 10x and release from there (going > from 8.8 to 10.0 directly, skipping 9x altogether). > > > > Tldr, we shall have complete flexibility to go in any direction we want > to. > > > > WDYT? > > > > On Sun, 4 Oct, 2020, 2:31 am Uwe Schindler, <[email protected]> wrote: > >> Is the branch ready for Jenkins testing? > >> > >> If yes and "gradlew check" works, I really would like to set it up. > >> > >> Uwe > >> > >> Am October 3, 2020 7:42:22 PM UTC schrieb Ishan Chattopadhyaya < > [email protected]>: > >>> Hi Devs, > >>> > >>> As you might be aware, the reference_impl branch has a lot of > improvements that we want to see in Solr master. However, it is currently a > large deviation from master and hence the stability and reliability (though > improved in certain aspects) remains to be tested in real production > environments before we gain confidence in bringing those changes to master. > >>> > >>> I propose that we do a one off preview release from that branch, say > Solr 10 alpha (early access) or any other name that someone suggests, so > that users could try it out and report regressions or improvements etc. > >>> > >>> I volunteer to be the RM and planning to start the process around 1 > December-15 December timeframe. Until then, we can tighten the loose ends > on the branch and plan for such a release. > >>> > >>> Is there any thoughts, concerns, questions? > >>> > >>> Regards, > >>> Ishan > >> > >> -- > >> Uwe Schindler > >> Achterdiek 19, 28357 Bremen > >> https://www.thetaphi.de > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
