ReleaseWizard tool

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

ReleaseWizard tool

Jan Høydahl / Cominvent
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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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

Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Ishan Chattopadhyaya
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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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

Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Jan Høydahl / Cominvent
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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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


Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Jan Høydahl / Cominvent
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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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



Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Chris Hostetter-3

: 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.

The reason we (should always) track every fixVersion based on where things
are commited & backported is because of how important it is from the stand
point of knowing when exactly something was fixed, compared to where it
might have *needed* to be fixed.  

A bug might be found just before the 8.1.0 release that affect 7.7.0,
8.0.0, and the current branch_8x but not master because the underlying
functionality was deprecated in 8x & removed from master -- the fix would
be committed to branch_8x and backported to branch_8_0 and branch_7_7 for
inclusion in 7.7.1 -- but maybe no one has bothered with w/an 8.0.1, and
meanwhile branch_8_1 is forked from branch_8x and already has the fix.

if we *only* record fixVersion=7.7.1, then that can misslead people who
don't know the timing/history of the jira into thinking that if it was
fixed in 7.7.y then maybe/probably/who-knows-if it is issue in 8.x.y.  
Having fixVersion=7.7.1,8.0.1,8.1.0 helps communicate several things...
 
* if you are using 7.y.x lower then 7.7.1 you might be affected by this
* if you are using 8.0.y lower then 8.0.1 you might be affected by this
  - since you can see in jira that 8.0.1 is unreleased:
    - if/when 8.0.1 is released, it will include this fix
* if you are using 8.x.y lower then 8.1.0 then you might be affected by this

If we *only* use fixVersion="lowest version released" it wouldn't help
people answer the question "Does this bug exist in 8.w.v if all i know is that
the _first_ version it was fixed in was 7.x.y?"

...not to mention the complexity involved in _older_ bug fixe releases
happening *after* more recent feature releases with the same fix (ie:
7.7.1 being released after 8.1.0.

(a more rigorous use of the "affectsVersion", eg:
affectsVersion="7.7.0,7.7.1,...,7.7.0,8.0.0", can help mitigate *some*
of this confusion -- by implying that the issue does *not* affect 8.1.0
since it isn't listed there -- but that's a lot more tedious to maintain
then just ensuring that you add a fixVersion for every place you commit)


-Hoss
http://www.lucidworks.com/

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

Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Jan Høydahl / Cominvent
Thanks for input. I’ll start a separate email thread for discussing how we use JIRA including fixVersion :)

Jan Høydahl

> 30. mai 2019 kl. 01:43 skrev Chris Hostetter <[hidden email]>:
>
>
> : 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.
>
> The reason we (should always) track every fixVersion based on where things
> are commited & backported is because of how important it is from the stand
> point of knowing when exactly something was fixed, compared to where it
> might have *needed* to be fixed.  
>
> A bug might be found just before the 8.1.0 release that affect 7.7.0,
> 8.0.0, and the current branch_8x but not master because the underlying
> functionality was deprecated in 8x & removed from master -- the fix would
> be committed to branch_8x and backported to branch_8_0 and branch_7_7 for
> inclusion in 7.7.1 -- but maybe no one has bothered with w/an 8.0.1, and
> meanwhile branch_8_1 is forked from branch_8x and already has the fix.
>
> if we *only* record fixVersion=7.7.1, then that can misslead people who
> don't know the timing/history of the jira into thinking that if it was
> fixed in 7.7.y then maybe/probably/who-knows-if it is issue in 8.x.y.  
> Having fixVersion=7.7.1,8.0.1,8.1.0 helps communicate several things...
>
> * if you are using 7.y.x lower then 7.7.1 you might be affected by this
> * if you are using 8.0.y lower then 8.0.1 you might be affected by this
>  - since you can see in jira that 8.0.1 is unreleased:
>    - if/when 8.0.1 is released, it will include this fix
> * if you are using 8.x.y lower then 8.1.0 then you might be affected by this
>
> If we *only* use fixVersion="lowest version released" it wouldn't help
> people answer the question "Does this bug exist in 8.w.v if all i know is that
> the _first_ version it was fixed in was 7.x.y?"
>
> ...not to mention the complexity involved in _older_ bug fixe releases
> happening *after* more recent feature releases with the same fix (ie:
> 7.7.1 being released after 8.1.0.
>
> (a more rigorous use of the "affectsVersion", eg:
> affectsVersion="7.7.0,7.7.1,...,7.7.0,8.0.0", can help mitigate *some*
> of this confusion -- by implying that the issue does *not* affect 8.1.0
> since it isn't listed there -- but that's a lot more tedious to maintain
> then just ensuring that you add a fixVersion for every place you commit)
>
>
> -Hoss
> http://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: ReleaseWizard tool

Michael Sokolov-4
In reply to this post by Jan Høydahl / Cominvent
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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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



Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Jan Høydahl / Cominvent
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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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



Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Jan Høydahl / Cominvent
I have now pushed the ReleaseWizard tool in https://issues.apache.org/jira/browse/LUCENE-8852
Appreciate all kind of feedback!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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




Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Jan Høydahl / Cominvent
I wrote an article at LinkedIN pulse about the release process and the tool:

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

11. jun. 2019 kl. 10:46 skrev Jan Høydahl <[hidden email]>:

I have now pushed the ReleaseWizard tool in https://issues.apache.org/jira/browse/LUCENE-8852
Appreciate all kind of feedback!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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





Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

david.w.smiley@gmail.com
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


On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl <[hidden email]> wrote:
I wrote an article at LinkedIN pulse about the release process and the tool:

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

11. jun. 2019 kl. 10:46 skrev Jan Høydahl <[hidden email]>:

I have now pushed the ReleaseWizard tool in https://issues.apache.org/jira/browse/LUCENE-8852
Appreciate all kind of feedback!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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





Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Jan Høydahl / Cominvent
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 <[hidden email]>:

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


On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl <[hidden email]> wrote:
I wrote an article at LinkedIN pulse about the release process and the tool:

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

11. jun. 2019 kl. 10:46 skrev Jan Høydahl <[hidden email]>:

I have now pushed the ReleaseWizard tool in https://issues.apache.org/jira/browse/LUCENE-8852
Appreciate all kind of feedback!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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





Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Cassandra Targett
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 <[hidden email]>, 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 <[hidden email]>:

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


On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl <[hidden email]> wrote:
I wrote an article at LinkedIN pulse about the release process and the tool:

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

11. jun. 2019 kl. 10:46 skrev Jan Høydahl <[hidden email]>:

I have now pushed the ReleaseWizard tool in https://issues.apache.org/jira/browse/LUCENE-8852
Appreciate all kind of feedback!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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





Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Ishan Chattopadhyaya
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, <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]>:

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


On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl <[hidden email]> wrote:
I wrote an article at LinkedIN pulse about the release process and the tool:

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

11. jun. 2019 kl. 10:46 skrev Jan Høydahl <[hidden email]>:

I have now pushed the ReleaseWizard tool in https://issues.apache.org/jira/browse/LUCENE-8852
Appreciate all kind of feedback!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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





Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Jan Høydahl / Cominvent
In reply to this post by Cassandra Targett
It has nothing to do with the RefGuide :)
It will generate a "release TODO" document in adoc format for this specific release, which details all the phases, all the steps in each phase, and all the exact cmdline commands, with correct paths and version numbers, to run for each step.
You don't really need it, because the interactive CLI menus in the tool keeps you up to date on what steps remain and what to do, but it is nice for a full overview of the process for preparation or whatever.
The guide will be different if you are doing a major, minor or bugfix release, as there are different steps needed for each.
Then we generate a HTML page with embedded CSS from the adoc, see <a href="https://www.dropbox.com/s/ug9yckvbwqwetvs/Lucene:Solr Release 8.3.0.html?dl=0" class="">https://www.dropbox.com/s/ug9yckvbwqwetvs/Lucene%3ASolr%20Release%208.3.0.html?dl=0 for an example HTML, and https://www.dropbox.com/s/wulog2ipweth4mp/lucene_solr_release_8.3.0.adoc?dl=0 for the corresponding adoc. Try it :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

6. nov. 2019 kl. 21:32 skrev Cassandra Targett <[hidden email]>:

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 <[hidden email]>, 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 <[hidden email]>:

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


On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl <[hidden email]> wrote:
I wrote an article at LinkedIN pulse about the release process and the tool:

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

11. jun. 2019 kl. 10:46 skrev Jan Høydahl <[hidden email]>:

I have now pushed the ReleaseWizard tool in https://issues.apache.org/jira/browse/LUCENE-8852
Appreciate all kind of feedback!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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






Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Cassandra Targett
That explains it - I suspected it didn’t have anything to do with the Ref Guide, but wanted to be sure.

Very nice, thanks for working on it!

Cassandra
On Nov 6, 2019, 2:48 PM -0600, Jan Høydahl <[hidden email]>, wrote:
It has nothing to do with the RefGuide :)
It will generate a "release TODO" document in adoc format for this specific release, which details all the phases, all the steps in each phase, and all the exact cmdline commands, with correct paths and version numbers, to run for each step.
You don't really need it, because the interactive CLI menus in the tool keeps you up to date on what steps remain and what to do, but it is nice for a full overview of the process for preparation or whatever.
The guide will be different if you are doing a major, minor or bugfix release, as there are different steps needed for each.
Then we generate a HTML page with embedded CSS from the adoc, see https://www.dropbox.com/s/ug9yckvbwqwetvs/Lucene%3ASolr%20Release%208.3.0.html?dl=0 for an example HTML, and https://www.dropbox.com/s/wulog2ipweth4mp/lucene_solr_release_8.3.0.adoc?dl=0 for the corresponding adoc. Try it :)

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

6. nov. 2019 kl. 21:32 skrev Cassandra Targett <[hidden email]>:

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 <[hidden email]>, 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 <[hidden email]>:

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


On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl <[hidden email]> wrote:
I wrote an article at LinkedIN pulse about the release process and the tool:

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

11. jun. 2019 kl. 10:46 skrev Jan Høydahl <[hidden email]>:

I have now pushed the ReleaseWizard tool in https://issues.apache.org/jira/browse/LUCENE-8852
Appreciate all kind of feedback!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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






Reply | Threaded
Open this post in threaded view
|

Re: ReleaseWizard tool

Jan Høydahl / Cominvent
In reply to this post by Ishan Chattopadhyaya
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/
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

6. nov. 2019 kl. 21:46 skrev Ishan Chattopadhyaya <[hidden email]>:

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, <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]>:

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


On Thu, Jul 4, 2019 at 2:53 PM Jan Høydahl <[hidden email]> wrote:
I wrote an article at LinkedIN pulse about the release process and the tool:

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

11. jun. 2019 kl. 10:46 skrev Jan Høydahl <[hidden email]>:

I have now pushed the ReleaseWizard tool in https://issues.apache.org/jira/browse/LUCENE-8852
Appreciate all kind of feedback!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

1. jun. 2019 kl. 20:26 skrev Jan Høydahl <[hidden email]>:

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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]>:

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, <[hidden email]> 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:


  ┌─────────────────────────────────────────────────────────────────────────┐
  │                                                                         │
  │  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