It’s not true that “we cannot test the backcompatibility of the 6.5.0 branch with itself”. After releasing a *.0 releae, the RM can just set the release branch version to *.1, and then there are no issues with adding the *.0 backcompat indexes.
I believe the real reason these don’t get added to the release branches is economy of effort. It’s not certain that there will be a *.1 release after a *.0 release, so why bother? This is a constant source of confusion, though. Effort is definitely not economized when considering an RM who’s never done a bugfix release before. Some perspective: 8/12 of the 5.X and 6.X relase branches had, or will have (6.5.1), at least one bugfix release. It’s now the *ordinary* case that release branches will get a bugfix release. I think it’s time to change the ReleaseToDo to tell RMs to always generate the backcompat indexes on the release branch, regardless of whether the current release is a bugfix release. -- Steve www.lucidworks.com > On Apr 9, 2017, at 6:05 PM, jim ferenczi <[email protected]> wrote: > > Ok sorry I should have been more specific. The backcompat tests are not > created on the release branch for the first minor release (eg. 6.5.0). They > are only created for the master branch and the 6x branch. Then during the > first bugfix of the current release branch (eg. 6.5.1) we push the backcompat > test directly on the release branch. This is not done before because we > cannot test the backcompatibitily of the 6.5.0 branch with itself. > > 2017-04-09 22:57 GMT+02:00 Joel Bernstein <[email protected]>: > Thanks Jim, I don't quite understand the rational for when the backcompat > indexes are created, but that's OK. I'll create a new RC this evening. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Sun, Apr 9, 2017 at 4:44 PM, jim ferenczi <[email protected]> wrote: > Joel, > The backcompat indexes are not added for a minor release. They are added on > the first bugfix release on the minor branch. There is a note in the TODO: > "Make sure that the backcompat index for the previous release has been added > to the release branch. (Note that this will ordinarily not have been done if > the current release is X.Y.1, i.e. the first bugfix release off the stable > branch.) See the post-release section "Generate Backcompat Indexes" below - > remember you'll be generating an index for the previous release." > > I just pushed the backcompat indices in the release branch. You'll need to > generate a new release candidate though. > > 2017-04-09 3:15 GMT+02:00 Ishan Chattopadhyaya <[email protected]>: > No, this has not changed. I think backcompat indexes for the previous release > was not added. The 6.5.0 's RM might've missed this step. > > On Sun, Apr 9, 2017 at 4:45 AM, Joel Bernstein <[email protected]> wrote: > Looks like I need to add the back compat indexes. In the releaseTodo this is > post release activity but it looks that has changed. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Sat, Apr 8, 2017 at 6:58 PM, Joel Bernstein <[email protected]> wrote: > I don't believe I've missed any steps listed: > https://wiki.apache.org/lucene-java/ReleaseTodo > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Sat, Apr 8, 2017 at 6:56 PM, Joel Bernstein <[email protected]> wrote: > Ok, the keys appear to be sorted out now. Smoke test now gets much further > but fails with the error below. I'll go back see if I've missed a step... > Releases that don't seem to be tested: > > 6.5.0 > > Traceback (most recent call last): > > File "dev-tools/scripts/smokeTestRelease.py", line 1476, in <module> > > main() > > File "dev-tools/scripts/smokeTestRelease.py", line 1420, in main > > smokeTest(c.java, c.url, c.revision, c.version, c.tmp_dir, c.is_signed, ' > '.join(c.test_args)) > > File "dev-tools/scripts/smokeTestRelease.py", line 1458, in smokeTest > > unpackAndVerify(java, 'lucene', tmpDir, 'lucene-%s-src.tgz' % version, > gitRevision, version, testArgs, baseURL) > > File "dev-tools/scripts/smokeTestRelease.py", line 622, in unpackAndVerify > > verifyUnpacked(java, project, artifact, unpackPath, gitRevision, version, > testArgs, tmpDir, baseURL) > > File "dev-tools/scripts/smokeTestRelease.py", line 768, in verifyUnpacked > > confirmAllReleasesAreTestedForBackCompat(version, unpackPath) > > File "dev-tools/scripts/smokeTestRelease.py", line 1396, in > confirmAllReleasesAreTestedForBackCompat > > raise RuntimeError('some releases are not tested by > TestBackwardsCompatibility?') > > RuntimeError: some releases are not tested by TestBackwardsCompatibility? > > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Sat, Apr 8, 2017 at 2:53 PM, Joel Bernstein <[email protected]> wrote: > My key has appeared: http://home.apache.org/keys/group/lucene.asc. > > I'll work on an RC this evening. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Fri, Apr 7, 2017 at 5:33 PM, Joel Bernstein <[email protected]> wrote: > Ok, I've added the PGP fingerprint to my account on id.apache.org. I'll wait > until step #1 completes. > > Then I'll populate the three key files mentioned in Ishan's notes. > > Then I'll regenerate the RC. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Fri, Apr 7, 2017 at 5:20 PM, Joel Bernstein <[email protected]> wrote: > I need to get me public key into my profile on id.apache.org. I'll work on > that first. > > Joel Bernstein > http://joelsolr.blogspot.com/ > > On Fri, Apr 7, 2017 at 4:55 PM, Steve Rowe <[email protected]> wrote: > Joel, > > > > On Apr 7, 2017, at 4:36 PM, Steve Rowe <[email protected]> wrote: > > > > a key generated with gpg2 won’t be visible to gpg. > > Lower-impact fix (maybe) than symlinking - this will make your public key > visible to ‘gpg’: > > $ gpg --recv-key EE64CB1E > > -- > Steve > www.lucidworks.com > --------------------------------------------------------------------- > 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]
