Hi again, The "default" reference guide location still redirects to the 8_2 guide. The 8.2 release is still in our mirrors: http://www.apache.org/dist/lucene/solr/ <http://www.apache.org/dist/lucene/solr/>
You said you would come back to completing the post-release steps Ishan, there may be more steps than these two you missed. You are the 8.3.0 RM so only you would know what is completed and not? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com > 13. nov. 2019 kl. 22:01 skrev Jan Høydahl <[email protected]>: > > Ishan, do you have some feedback on the ReleaseWizard? > > Also I notice that the redirect to the latest refGuide is not changed on the > website, so e.g > https://lucene.apache.org/solr/guide/distributed-requests.html > <https://lucene.apache.org/solr/guide/distributed-requests.html> redirects to > 8_2 guide instead of 8_3 guide. > The reeleaseWizard has a step for that so I wonder if you skipped it or if it > was not clear or perhaps buggy? > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com <http://www.cominvent.com/> > >> 8. nov. 2019 kl. 10:19 skrev Jan Høydahl <[email protected] >> <mailto:[email protected]>>: >> >> Hi, >> >> Looking forward to feedback on the tool Ishan! >> >> One concrete question: >> I see that v8.2.0 is still in the release repo >> http://www.apache.org/dist/lucene/solr/ >> <http://www.apache.org/dist/lucene/solr/> >> The Wizard step "9.10. Stop mirroring old releases" should have told you to >> remove v8.2.0 form the repo. >> Did you not yet complete all steps in the Wizard or was there a bug so that >> step did not display for you? >> >> -- >> Jan Høydahl, search solution architect >> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> >> >>> 6. nov. 2019 kl. 21:46 skrev Ishan Chattopadhyaya >>> <[email protected] <mailto:[email protected]>>: >>> >>> Jan, I owe you the list of issues and filing of jiras regarding issues i >>> faced with the tool during 8.3.0. I'll try to do so this weekend. >>> >>> On Thu, 7 Nov, 2019, 2:03 AM Cassandra Targett, <[email protected] >>> <mailto:[email protected]>> wrote: >>> I was far too swamped back in July to be able to take a look at this new >>> tool, but I’ve had a few minutes now and while I’ve never done a release, >>> it really looks very helpful. >>> >>> Jan, I note in your initial description in this thread and in LUCENE-8852 >>> you mention the release wizard tool allows you to "generate a full Asciidoc >>> guide for the release” - what is it generating? I’m not a python expert, >>> but I did notice it requires & uses the asciidoctor gem. That’s not how we >>> make the Ref Guide so it must be for another purpose, but I’m not able to >>> fully figure it out. >>> >>> Sorry for the late thread resurrection, as I said I only now have a bit of >>> time to catch up here. >>> >>> Thanks, >>> Cassandra >>> On Jul 5, 2019, 3:11 PM -0500, Jan Høydahl <[email protected] >>> <mailto:[email protected]>>, wrote: >>>> Go for it. For me it was a very interesting experience, and I will likely >>>> do it again at some point! >>>> >>>> Jan Høydahl >>>> >>>> 5. jul. 2019 kl. 21:00 skrev David Smiley <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>>> Nice Jan! Maybe I'll be an RM one day, now that there's a nice tool to >>>>> help :-) >>>>> >>>>> ~ David Smiley >>>>> Apache Lucene/Solr Search Developer >>>>> http://www.linkedin.com/in/davidwsmiley >>>>> <http://www.linkedin.com/in/davidwsmiley> >>>>> >>>>> On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> I wrote an article at LinkedIN pulse about the release process and the >>>>> tool: >>>>> https://www.linkedin.com/pulse/releasing-lucene-just-61-steps-jan-høydahl/ >>>>> >>>>> <https://www.linkedin.com/pulse/releasing-lucene-just-61-steps-jan-h%C3%B8ydahl/> >>>>> >>>>> -- >>>>> Jan Høydahl, search solution architect >>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> >>>>> >>>>>> 11. jun. 2019 kl. 10:46 skrev Jan Høydahl <[email protected] >>>>>> <mailto:[email protected]>>: >>>>>> >>>>>> I have now pushed the ReleaseWizard tool in >>>>>> https://issues.apache.org/jira/browse/LUCENE-8852 >>>>>> <https://issues.apache.org/jira/browse/LUCENE-8852> >>>>>> Appreciate all kind of feedback! >>>>>> >>>>>> -- >>>>>> Jan Høydahl, search solution architect >>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> >>>>>> >>>>>>> 1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[email protected] >>>>>>> <mailto:[email protected]>>: >>>>>>> >>>>>>> As I said, I’ll start a thread about this, please reply to that instead >>>>>>> of continuing discussion in this thread which is about releaseWizard :) >>>>>>> >>>>>>> Jan Høydahl >>>>>>> >>>>>>> 1. jun. 2019 kl. 15:53 skrev Michael Sokolov <[email protected] >>>>>>> <mailto:[email protected]>>: >>>>>>> >>>>>>>> I'm not sure what the proper way to use fix version is. Suppose you >>>>>>>> back port a fix to multiple branches? Should fixVersion list all of >>>>>>>> them? Just pick one? >>>>>>>> >>>>>>>> On Wed, May 29, 2019, 6:00 PM Jan Høydahl <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> My releaseWizard tool is getting more complete as the 7.7.2 release >>>>>>>> progresses. Will share the code just after I complete all steps. >>>>>>>> >>>>>>>> I tested relasedocmaker and it digs up all the JIRA issues marked as >>>>>>>> RESOLVED for the version and creates two files. >>>>>>>> CHANGELOG.md simply lists all issues under headings IMPROVEMENTS, BUG >>>>>>>> FIXES etc >>>>>>>> One problem I found with how the CHANGELOG works is that it adds all >>>>>>>> issues having the version in fixVersion, even if the feature >>>>>>>> was already released in an earlier version. That is because of the way >>>>>>>> we use JIRA fixVersion, adding both e.g. "master (9.0)" and "8.2" >>>>>>>> at the same time, even if we know that 8.2 is the version the feature >>>>>>>> will be released. If we stop always adding "master" to fixVersion >>>>>>>> but strive to keep it a list of version the feature/bugfix is FIRST >>>>>>>> introduced, then this tool will do the correct job. >>>>>>>> >>>>>>>> RELEASENOTES.md lists "...new developer and user-facing >>>>>>>> incompatibilities, important issues, features, and major >>>>>>>> improvements.". >>>>>>>> And if we enable the JIRA field "Release Notes" (we don't have it >>>>>>>> now), the content of that field will be used in the release notes >>>>>>>> instead of the JIRA description. >>>>>>>> You can select any issue to surface in RELEASENOTES by adding a >>>>>>>> certain label, by default "backward-incompatible". >>>>>>>> >>>>>>>> I think it could be a welcome addition to our flow. We cant' expect >>>>>>>> the output from the tool to be used as-is, sometimes a major feature >>>>>>>> spans multiple >>>>>>>> JIRAs etc, but it could be a good starting point, and would shift the >>>>>>>> burden of documenting important and breaking changes from release-time >>>>>>>> to commit-time, >>>>>>>> if we as committers manage to adjust our routines. We could even have >>>>>>>> a weekly job that runs the releasedocmaker and sends the output to >>>>>>>> dev@ list for active branches, to keep focus. >>>>>>>> >>>>>>>> -- >>>>>>>> Jan Høydahl, search solution architect >>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> >>>>>>>> >>>>>>>>> 17. mai 2019 kl. 13:45 skrev Jan Høydahl <[email protected] >>>>>>>>> <mailto:[email protected]>>: >>>>>>>>> >>>>>>>>> Yes, I thought we could use >>>>>>>>> https://yetus.apache.org/documentation/0.10.0/releasedocmaker/ >>>>>>>>> <https://yetus.apache.org/documentation/0.10.0/releasedocmaker/> to >>>>>>>>> generate the draft, and this could be wired into the releaseWizard >>>>>>>>> tool. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Jan Høydahl, search solution architect >>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> >>>>>>>>> >>>>>>>>>> 17. mai 2019 kl. 06:40 skrev Ishan Chattopadhyaya >>>>>>>>>> <[email protected] <mailto:[email protected]>>: >>>>>>>>>> >>>>>>>>>> Much needed. Thanks for working on it. >>>>>>>>>> >>>>>>>>>> Here's an idea I was thinking about yesterday: the most tedious step >>>>>>>>>> is to generate release highlights. We should have a JIRA field >>>>>>>>>> "release highlight" which, when populated, will have the text that >>>>>>>>>> will be featured in the announce mail and on the website in news. >>>>>>>>>> That way, generating those mails can be semi/fully automated. >>>>>>>>>> >>>>>>>>>> Alternatively, this field can just be a Boolean check box and title >>>>>>>>>> of the Jira can be used as highlight. This will force the committer >>>>>>>>>> to keep meaningful titles. >>>>>>>>>> >>>>>>>>>> On Thu, 16 May, 2019, 10:58 PM Jan Høydahl, <[email protected] >>>>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>>>> Just a heads-up that as part of my releasing 7.7.2 effort I'm also >>>>>>>>>> hacking on >>>>>>>>>> a releaseWizard script to replace the ReleaseTodo wiki page. It will >>>>>>>>>> act as a >>>>>>>>>> checklist where you see tasks that needs to be done (different for >>>>>>>>>> major/minor/bug) >>>>>>>>>> and mark those completed. It will also run all the commands for you >>>>>>>>>> and preserve >>>>>>>>>> the logs, generate e-mail templates with all versions, dates etc in >>>>>>>>>> place, handle >>>>>>>>>> voting rules and counting etc. It will also generate an asciidoc + >>>>>>>>>> HTML page that >>>>>>>>>> gives a nice overview of the whole thing :) >>>>>>>>>> >>>>>>>>>> Here's a teaser: >>>>>>>>>> >>>>>>>>>> https://asciinema.org/a/246656 <https://asciinema.org/a/246656> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ┌─────────────────────────────────────────────────────────────────────────┐ >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ Releasing Lucene/Solr 7.7.2 RC1 >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ Please complete the below checklist (Complete: 4/11) >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ 1 - ✓ Prerequisites (3/3) >>>>>>>>>> │ >>>>>>>>>> │ 2 - ✓ Work with the community to decide when and how etc >>>>>>>>>> (1/1) │ >>>>>>>>>> │ 3 - ✓ Create branch (if needed) and update versions (4/4) >>>>>>>>>> │ >>>>>>>>>> │ 4 - ✓ Add new versions to JIRA (2/2) >>>>>>>>>> │ >>>>>>>>>> │ 5 - Build the release artifacts (2/3) >>>>>>>>>> │ >>>>>>>>>> │ 6 - Hold the vote and sum up the results (0/2) >>>>>>>>>> │ >>>>>>>>>> │ 7 - Publish the release artifacts (0/1) >>>>>>>>>> │ >>>>>>>>>> │ 8 - Update the website (0/1) >>>>>>>>>> │ >>>>>>>>>> │ 9 - Update the DOAP file (0/1) >>>>>>>>>> │ >>>>>>>>>> │ 10 - Announce the release (0/1) >>>>>>>>>> │ >>>>>>>>>> │ 11 - Tasks to do after release (0/1) >>>>>>>>>> │ >>>>>>>>>> │ 12 - Exit >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> │ >>>>>>>>>> >>>>>>>>>> └─────────────────────────────────────────────────────────────────────────┘ >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Jan Høydahl, search solution architect >>>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >> >
