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]> 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 > > 17. mai 2019 kl. 13:45 skrev Jan Høydahl <[email protected]>: > > Yes, I thought we could use > 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 > > 17. mai 2019 kl. 06:40 skrev Ishan Chattopadhyaya < > [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]> 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 >> >> >> ┌─────────────────────────────────────────────────────────────────────────┐ >> │ >> │ >> │ 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 >> >> > >
