> I think the Solr 4 alpha/beta situation was different -- it was not some fork a committer was maintaining; it was the master branch of its time, and it was destined to be the very next release, not some possible future release.
Agree, 4’s alpha/beta was a very different situation. > I believe it has to be an official release to have enough credibility. People trust the Apache brand and the community. This will ensure that we get enough people to test this out. The very objective of this release is to get help from our users to uncover any bugs. Most big shops will not deploy unofficial releases in their prod/staging environments. We wish to tick all the boxes for our users I think this is fooling ourselves/our users. They trust Apache releases because we take them seriously, because they have the community behind, etc. This is a release from a feature branch, so we have to be cautious and very upfront. While I hope many go and test it and maybe deploy it to some of their environments, I feel we need to be careful not to send the wrong message. > I'm -0 on doing an official release for alpha software because it's unnecessary to achieve the goals and somewhat confusing I’d say I’m -1 to make it an official release for those reasons. I think we should try to merge into master (whenever you are comfortable? Does it need to wait until 9.0 is out? What's the main reason for that? can we split the parts that do need to wait vs the ones that don’t?) and then people can be encouraged to run a nightly version in their test environments to help debug possible instability. If we need to do alpha/beta versions from master then I think that would make more sense. On Mon, Oct 5, 2020 at 12:30 PM David Smiley <dsmi...@apache.org> wrote: > Thanks so much for your responses Ishan... I'm getting much more > information in this thread than my attempts to get questions answered on > the JIRA issue months ago. And especially, thank you for volunteering for > the difficult porting efforts! > > Tomas said: > >> I do agree with the previous comments that calling it "Solr 10" (even >> with the "-alpha") would confuse users, maybe use "reference"? or maybe >> something in reference to SOLR-14788? >> > > I have the opposite opinion. This word "reference" is baffling to me > despite whatever Mark's explanation is. I like the justification Ishan > gave for 10-alpha and I don't think I could re-phrase his justification any > better. *If* the release was _not_ official (thus wouldn't show up in the > usual places anyone would look for a release), I think it would alleviate > that confusion concern even more, although I think "alpha" ought to be > enough of a signal not to use it without digging deeper on what's going on. > > Alex then Ishan said: > >> > Maybe we could release it to >> > committers community first and dogfood it "internally"? >> >> Alex: It is meaningless. Committers don't run large scale installations. >> We barely even have time to take care of running unit tests before >> destabilizing our builds. We are not the right audience. However, we all >> can anyway check out the branch and start playing with it, even without a >> release. There are orgs that don't want to install any code that wasn't >> officially released; this release is geared towards them (to help us test >> this at their scale). >> > > I don't think it can be said what committers do and don't do with regards > to running Solr. All of us would answer this differently and at different > points in time. From time to time, though not at present, I've been well > positioned to try out a new version of Solr in a stage/test environment to > see how it goes. (Putting on my Salesforce metaphorical hat...) Even > though I'm not able to deploy it in a realistic way today, I'm able to run > a battery of tests to see if one of the features we depend on have changed > or is broken. That's useful feedback to an alpha release! And even though > I'm saying I'm not well positioned to try out some new Solr release in a > production-ish setting now, it's something I could make a good case for > internally since upgrades take a lot of effort where I work. It's in our > interest for SolrCloud to be very stable (of course). > > Regardless, I think what you're driving at Ishan is that you want an > "official" release -- one that goes through the whole ceremony. You > believe that people would be more likely to use it. I think all we need to > do is announce (similar to a real release) that there is some unofficial > alpha distribution and that we want to solicit your feedback -- basically, > help us find bugs. Definitely publish a Docker image BTW -- it's the best > way to try out any software. I'm -0 on doing an official release for alpha > software because it's unnecessary to achieve the goals and somewhat > confusing. I think the Solr 4 alpha/beta situation was different -- it was > not some fork a committer was maintaining; it was the master branch of its > time, and it was destined to be the very next release, not some possible > future release. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley >
