RELEASE NOTES: Difference between revisions

From Freephile Wiki
No edit summary
link to script and example
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
You've studied the [[Git/hacks]] and built a ton of features, fixes, and updates to your codebase in a sprint worthy of Usain Bolt
[[File:Hussein Bolt.png|thumb]]
[[File:Hussein Bolt.png|thumb]]
. Now it's time to create some release notes - which in the tradition of open source is stored in the RELEASE_NOTES file of your project.
You've studied the [[Git/hacks]] and built a ton of features, fixes, and updates to your codebase in a sprint worthy of Usain Bolt. Now it's time to create some release notes - which in the tradition of open source is stored in the RELEASE_NOTES file of your project.


Since your team follows the best practices of writing good commit comments and also creating appropriate branches and pull requests, then it's a simple matter of letting ```git``` tell you what's in the release. Of course you can amend or add to it as needed.
Since your team follows the best practices of writing good commit comments and also creating appropriate branches and pull requests, then it's a simple matter of letting '''[[git]]''' tell you what's in the release. Of course you can amend or add to it as needed.


<ol>
<ol>
<li> find the last parent branch
<li> First, study [[git/log]] for how to use the log command.</li>
see [[Git/hacks#How_did_I_get_here?]] </li>
<li> Optionally, if you are adopting a formal process for the first time and do not want to go all the way back in time to publish your release notes, you might need to figure out the say the last parent branch where you want to 'start' your notes.
<li> do a <code>git log --stat</code> or <code>git log --pretty</code> between the prior branch and HEAD</li>
See [[Git/hacks#How_did_I_get_here?]] </li>
<li> Iterate on  git log commands to find the one that works for you. E.g. <code>git log --stat</code> or <code>git log --pretty</code> between the prior branch/tag and HEAD (or current release tag)</li>
</ol>
</ol>


You'll get output like the following:
In the final analysis, use '''<tt>--no-merges</tt>'''<br>
<pre>
to show the whole commit history, but skip any merge commits so that the Release Notes are not cluttered with workflow items.
git log --pretty feature-kibana..HEAD
commit 7bc8622d5fa46f7cbfb001b45c04fcdb4d55ed0c (HEAD -> qb-1.43, tag: 43.4.7, origin/qb-1.43)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Fri Jan 24 02:18:59 2025 +0000


    Finish off Maintenance Script improvements
<code>git log --no-merges --format="%(decorate:prefix=,suffix=%n,tag=%n## Meza ,separator= )* %h (%as) %an: %s %b" 39.5.0...HEAD > RELEASE_NOTES-UPDATE.md</code> generates a pretty good update to the RELEASE_NOTES since v39.5.0 which is then manually reviewed and edited to clarify commit messages; add links etc.
   
    Last commits for this round of maintenance script operations
    Fixes Issue #142


commit 7cb9091831caf8a3f72d9c8de44310f5c9e1ad9e (tag: 43.7.1)
== Current Method ==
Author: Greg Rundlett <greg.rundlett@gmail.com>
Using a combination of <code>git log</code> to produce the Notes
Date:  Fri Jan 24 02:12:42 2025 +0000


    Add comments for $smwgParserFeatures (Links In Values feature)
plus <code>sed</code> to convert commit SHAs to  GitHub links


commit ab10ebe10fa294f4a8ce456269107281f2e2de18
and convert Issue references to GitHub Issue links, we get a pretty good RELEASE NOTES for any given range of commits.
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Fri Jan 17 19:08:51 2025 +0000


    Maintenance Script update (missed these)
By naming the file .md, and creating the links in markdown format, we can see the links as clickable in both GitHub and in VSCode with Markdown preview, bringing interactivity to the notes where developers want to drill down into details.
   
    Convert script calls to go through executable
    'maintenance/run'
    For extensions, use the class naming pattern
    'Extension:ClassName'
    Fixes Issue #142


commit ca1791040ebf7ea5e7ff4cef04f6c3ef2d56f2d2 (tag: 43.4.6)
Bash example 'one-liner'<syntaxhighlight lang="bash">
Author: Greg Rundlett <greg.rundlett@gmail.com>
export START=43.25.11; \
Date:   Fri Jan 17 19:01:19 2025 +0000
export END=43.29.1; \
git log --no-merges --name-status --format="%(decorate:prefix=,suffix=%n,tag=%n## Meza ,separator= )* %h (%as) %an: %s %b" $START..$END \
| sed -E 's/\* ([0-9a-f]{8})/\* [\1](https:\/\/github.com\/freephile\/meza\/commit\/\1)/g'  \
| sed -E 's/Issue # ?([0-9]{1,4})/Issue [#\1](https:\/\/github.com\/freephile\/meza\/issues\/\1)/Ig' \
> RELEASE_NOTES-$END.md
</syntaxhighlight>We formalized it and turned it into a script: [https://github.com/freephile/meza/blob/main/src/scripts/generate-release-notes.sh generate-release-notes.sh]


    Finish Maintenance Script update
See Meza [https://github.com/freephile/meza/blob/main/RELEASE_NOTES-43.29.1.md RELEASE_NOTES-43.29.1.md] as an example of the output.
   
    Convert script calls to go through executable
    'maintenance/run'
    For extensions, use the class naming pattern
    'Extension:ClassName'
    Fixes Issue #142


commit d624f7b4fbed42033dd8b6da3e786f9c1de53340 (tag: 43.6.1)
== In MediaWiki ==
Author: Greg Rundlett <greg.rundlett@gmail.com>
In the MediaWiki project, Release Notes are a hybrid mix of "CHANGELOG" (what I would call a pure version control / issue tracker list) plus "Product" notes about new features, deprecations and the important highlights of the release. For each release, there is a file produced with the naming convention of RELEASE-NOTES-''1.NN'' with all prior contents stored chronologically in the HISTORY file.
Date:  Thu Jan 16 23:48:54 2025 +0000


    A new tool to inspect the git repos on the controller
See [[mediawikiwiki:Release_notes/1.43|on-wiki RELEASE NOTES for version 1.43]] and the [https://github.com/wikimedia/mediawiki/blob/05631d4fe4eeb32fac725072a8e57b61f3ebd7b9/RELEASE-NOTES-1.43 RELEASE-NOTES-1.43] file in the repository.


commit e267f14854957206ba556812038c357e27db0116 (tag: 43.4.5)
See Also: https://www.mediawiki.org/wiki/Release_notes/data
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Thu Jan 16 23:48:12 2025 +0000
 
    Update the Update.php role for new Maintenance script ops
   
    Issue #142
 
commit 9e4de5e18ad148ff47660c6c22b5dbf6ace5c940 (tag: 43.4.4)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Thu Jan 16 23:46:57 2025 +0000
 
    Update maintenance scripts
   
    Server Performance logging/reporting role
    (Probably needs to be eliminated altogether)
    Issue #142
 
commit 278c394ee70a00d86abcf13f434f6677723436b6 (tag: 43.4.3)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Thu Jan 16 23:45:38 2025 +0000
 
    Update maintenance scripts
   
    showSiteStats and refreshLinks
    Issue #142
 
commit 57c9bb20231e76fed948d22ea93714cff24d53c6 (tag: 43.4.2)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Thu Jan 16 23:44:01 2025 +0000
 
    Disable metastore maintenance
   
    All maintenance needs to be refactored
    Issue #142
    Also, this may be affected by upgrading to SMW 5.x
    Issue #136
 
commit 7ad66760bc98bfdf95f7774ad920c669510ca784 (tag: 43.5.1)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Thu Jan 16 23:42:08 2025 +0000
 
    Prefer source in composer managed extensions
   
    Use the --prefer-source option to composer
    Eliminate the duplicate composer run
    Eliminate the removal of a non-existant SMW file (IdeAliases.php)
    needed for Issue #136
 
commit f87b92b261035b4e8f91a169ecf9b286303de61c (tag: 43.4.1)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Thu Jan 16 23:32:29 2025 +0000
 
    Update maintenance scripts for MediaWiki 1.40
   
    Fixes Issue #142
 
commit 4ca775d65b3f64907dd87990af28073d454702fa (tag: 43.3.1)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Thu Jan 16 22:56:48 2025 +0000
 
    Update MezaCoreExtensions.yml for REL1_43
   
    Use full enableSemantics() call to fix URL pattern
    Switch to gerrit because GitHub seems to throttle
    SemanticDrilldown 3.05 -> dev-master
    SemanticScribunto 2.2.0 -> dev-master
    add quotes on SemanticDrilldown version spec
    add quotes on SubPageList version spec
 
commit e2873948a30a02fb56a8be6d40181f76101fad1c (tag: 43.2.1)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Fri Jan 10 17:45:00 2025 +0000
 
    Create a variable named php_memory_limit defaulting to 128M
   
    PHP normally defaults to 128M so we also default to that.
    Templated in the php.ini template of the apache-php role.
    Fixes issue #151
 
commit 51c89233b3279fbdd76c371cbdd5f9b17552d614 (tag: 43.1.2)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Wed Jan 8 01:39:19 2025 +0000
 
    Enable SemanticCompoundQueries
   
    Was 2.2.0
    Now 3.x-dev (same as dev-master)
    Issue #140
 
commit d2a87e79e3f039f7c81cc2ca091959698a11d99c (tag: 43.1.1)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Wed Jan 8 00:43:17 2025 +0000
 
    Use SubPageList dev-master
   
    Fixes issue #138
 
commit ca17aac64a4c1cd83be7ea4f22ac6b2732bdce06 (tag: 43.0.3)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Tue Jan 7 21:38:15 2025 +0000
 
    Disable or update non-working skins
   
    These skins need a version adjustment or update
    to work with REL1_43
    - Tweeki
    - Medik
   
    Use tags/v4.39.1 for Tweeki
    Issue #136
 
commit cde7d8cfaa866bbcba6de5b32b34f1d94b1134e6 (tag: 43.0.2)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Tue Jan 7 21:09:29 2025 +0000
 
    Disable non-working extensions
   
    These extensions do not work, or need a version adjustment,
    to be compatible with REL1_43 and SMW 5.x
    - SemanticCompoundQueries
    - SemanticDependencyUpdater
    - SemanticDrilldown
    - SemanticExtraSpecialProperties
    - SemanticResultFormats
    - SemanticScribunto
    - SubPageList
 
commit 36567d8330bef1a28d923fd0f351f7ef6e26bdd8 (tag: 43.0.1)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Tue Jan 7 21:04:38 2025 +0000
 
    Switch SMW to dev-master
   
    Addresses Issue #137
    composer show -a mediawiki/semantic-media-wiki
    shows all available composer versions
 
commit d7d6a88ecebedf8eb2a2d476d26d937696ba2809 (tag: 43.0.0)
Author: Greg Rundlett <greg.rundlett@gmail.com>
Date:  Tue Jan 7 17:33:33 2025 +0000
 
    Upgrade to REL1_43
   
    Fixes Issue #136
    set meza_repository_url to use freephile/meza
    set mediawiki_version for core
    set mediawiki_default_branch (for extensions)
    set php_ius_version to php81
</pre>
 
I've written up fancier routines for this, but every time they're lost to the client where I've implemented them so this article is a stub to record and improve on the existing practices. See for instance: https://www.mediawiki.org/wiki/Release_notes/data


[[Category:Best Practices]]
[[Category:Best Practices]]

Latest revision as of 00:38, 27 August 2025

You've studied the Git/hacks and built a ton of features, fixes, and updates to your codebase in a sprint worthy of Usain Bolt. Now it's time to create some release notes - which in the tradition of open source is stored in the RELEASE_NOTES file of your project.

Since your team follows the best practices of writing good commit comments and also creating appropriate branches and pull requests, then it's a simple matter of letting git tell you what's in the release. Of course you can amend or add to it as needed.

  1. First, study git/log for how to use the log command.
  2. Optionally, if you are adopting a formal process for the first time and do not want to go all the way back in time to publish your release notes, you might need to figure out the say the last parent branch where you want to 'start' your notes. See Git/hacks
  3. Iterate on git log commands to find the one that works for you. E.g. git log --stat or git log --pretty between the prior branch/tag and HEAD (or current release tag)

In the final analysis, use --no-merges
to show the whole commit history, but skip any merge commits so that the Release Notes are not cluttered with workflow items.

git log --no-merges --format="%(decorate:prefix=,suffix=%n,tag=%n## Meza ,separator= )* %h (%as) %an: %s %b" 39.5.0...HEAD > RELEASE_NOTES-UPDATE.md generates a pretty good update to the RELEASE_NOTES since v39.5.0 which is then manually reviewed and edited to clarify commit messages; add links etc.

Current Method

Using a combination of git log to produce the Notes

plus sed to convert commit SHAs to GitHub links

and convert Issue references to GitHub Issue links, we get a pretty good RELEASE NOTES for any given range of commits.

By naming the file .md, and creating the links in markdown format, we can see the links as clickable in both GitHub and in VSCode with Markdown preview, bringing interactivity to the notes where developers want to drill down into details.

Bash example 'one-liner'

export START=43.25.11; \
export END=43.29.1; \
git log --no-merges --name-status --format="%(decorate:prefix=,suffix=%n,tag=%n## Meza ,separator= )* %h (%as) %an: %s %b" $START..$END \
| sed -E 's/\* ([0-9a-f]{8})/\* [\1](https:\/\/github.com\/freephile\/meza\/commit\/\1)/g'  \
| sed -E 's/Issue # ?([0-9]{1,4})/Issue [#\1](https:\/\/github.com\/freephile\/meza\/issues\/\1)/Ig' \
> RELEASE_NOTES-$END.md

We formalized it and turned it into a script: generate-release-notes.sh

See Meza RELEASE_NOTES-43.29.1.md as an example of the output.

In MediaWiki

In the MediaWiki project, Release Notes are a hybrid mix of "CHANGELOG" (what I would call a pure version control / issue tracker list) plus "Product" notes about new features, deprecations and the important highlights of the release. For each release, there is a file produced with the naming convention of RELEASE-NOTES-1.NN with all prior contents stored chronologically in the HISTORY file.

See on-wiki RELEASE NOTES for version 1.43 and the RELEASE-NOTES-1.43 file in the repository.

See Also: https://www.mediawiki.org/wiki/Release_notes/data