6.5.1 release?

classic Classic list List threaded Threaded
44 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: 6.5.1 release?

Adrien Grand
Le lun. 10 avr. 2017 à 17:21, Steve Rowe <[hidden email]> a écrit :
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.

+1 to making the release process more consistent
Reply | Threaded
Open this post in threaded view
|

Re: 6.5.1 release?

Joel Bernstein
It may have slipped through the cracks because I started a vote on a Sunday night, but I cut RC1 last night. The vote is underway.


On Mon, Apr 10, 2017 at 11:41 AM, Adrien Grand <[hidden email]> wrote:
Le lun. 10 avr. 2017 à 17:21, Steve Rowe <[hidden email]> a écrit :
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.

+1 to making the release process more consistent

Reply | Threaded
Open this post in threaded view
|

Re: 6.5.1 release?

jim ferenczi
In reply to this post by sarowe
> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
> 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 <[hidden email]> 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 <[hidden email]>:
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> Joel,
>
>
> > On Apr 7, 2017, at 4:36 PM, Steve Rowe <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
>
>
>
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: 6.5.1 release?

sarowe
I updated the ReleaseToDo wiki page to specify running addVersion.py and addBackCompatIndexes.py on the release branch, regardless of release type.

--
Steve
www.lucidworks.com

> On Apr 10, 2017, at 12:23 PM, jim ferenczi <[hidden email]> wrote:
>
> > 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 <[hidden email]>:
> 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 <[hidden email]> 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 <[hidden email]>:
> > 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 <[hidden email]> 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 <[hidden email]>:
> > 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
> > Joel,
> >
> >
> > > On Apr 7, 2017, at 4:36 PM, Steve Rowe <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123