lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Sokolov <msoko...@gmail.com>
Subject Re: ReleaseWizard tool
Date Sat, 01 Jun 2019 13:53:44 GMT
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 <jan.asf@cominvent.com> 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 <jan.asf@cominvent.com>:
>
> 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 <
> ichattopadhyaya@gmail.com>:
>
> 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, <jan.asf@cominvent.com> 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
>>
>>
>
>

Mime
View raw message