[
https://issues.apache.org/jira/browse/SOLR-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030967#comment-18030967
]
Jan Høydahl commented on SOLR-17619:
------------------------------------
If we go with *one* "unreleased" folder, it simplifies some things for
developers for sure.
But we lose out on seing the pending features per version when peeking at the
main branch, as we have been able to so far. But perhaps that is not as
important. If we atuomate `logchange generate` a changelog file for each
branch, say nightly, it will show all unreleased work under the same header.
One could interpret that as:
_*"If* we were to do a release from thisthat branch today, these
features/bugfixes would be released for the first time"_
You'd need to visit the release branch to see what is up next for that version.
And a seldom corner case: If we release a bugfix e.g. 10.0.1 for a previous
minor on branch_10_0, *after* the next minor 10.1.0 is out (branch_10_1), then
the RM cannot remove those changelog yaml entries from the "unreleased" folder
of branch_10_1, since a user who has 10.1.0 and upgrades to 10.1.1 will see
those bug fixes for the first time. This corner case happens very seldom and
cam be solved by release wizard logic.
I'm willing to try a single "unreleased" folder for a few releases and then
evaluate.
> Generate CHANGELOG.md (formerly CHANGES.txt) via logchange
> ----------------------------------------------------------
>
> Key: SOLR-17619
> URL: https://issues.apache.org/jira/browse/SOLR-17619
> Project: Solr
> Issue Type: Task
> Components: Build
> Reporter: David Smiley
> Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The [logchange|https://github.com/logchange/logchange] tool helps projects
> maintain a log of changes. Each change (e.g. from a PR) will no longer edit a
> CHANGES.txt file; instead it will include a _new_ YAML file in an appropriate
> directory with others for the next Solr version. The release process will
> execute the tool, which will build a CHANGELOG.md file and will probably also
> do something with the YAML files (remove?).
> Decide the most convenient way for us to run the tool for change authors.
> Could a gradle task do it? See [this
> issue|https://github.com/logchange/logchange/issues/397] filed on the
> logchange project.
> Outcome of this issue:
> * a logchange tool configuration file -- logchange-config.yml
> * Solr 10's CHANGES.txt entries converted to YAML. (start this issue by
> doing only a few before over-investing)
> * a dev-docs page
> ** for contributors/everyone: basic info explaining how each new change
> should be recorded. Explain how to run the tool to generate the YAML file.
> What field(s) matter the most; what should be ignored. Link to further
> details.
> ** for release manager: how to produce CHANGELOG.md. Link to further
> details. Ultimately this will probably move to the release wizard in some
> fashion.
> TBD: CHANGES.txt < 10 and CHANGELOG.md > 10 ?
> TBD: changes.html generation in the release process will be removed or will
> change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
