> 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.
Yes if we add the next bugfix version in the release branch *after* the release. I spent some time last night trying to understand what happened so definitely +1 to make the process more consistent. 2017-04-10 17:21 GMT+02:00 Steve Rowe <[email protected]>: > 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] > >
