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 > 8. nov. 2019 kl. 10:19 skrev Jan Høydahl <[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/> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >
