[
https://issues.apache.org/jira/browse/SOLR-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030990#comment-18030990
]
Jan Høydahl commented on SOLR-17619:
------------------------------------
{quote}At the time of release, of course there will be automation. The
unreleased entries on the release branch will get removed, and incorporated
into a consolidated changelog file organized by version. That changelog file
will be "published" to higher version branches via forward porting (cherry
pick) the changelog commit, thus keeping the changelog file up to date and to
limit the folder size of what's unreleased.
{quote}
I don't think we'd cherry-pick a CHANGELOG.md file between branches. The
logchange tool (on the release branch) moves all files from {{unreleased/}}
into a new versioned folder (e.g., {{{}v10.1.0/{}}}). This versioned folder –
along with the deletion of those files from {{unreleased/}} – would be
cherry-picked forward to higher version branches, but not an MD file?
*Open questions:*
# *CHANGELOG.md generation for release artifacts:* Should we generate a
consolidated {{CHANGELOG.md}} file during the release?
** If yes, should it be committed to the release branch (for inclusion in the
tarball) as a generated-only file (never manually edited)?
** Or should {{CHANGELOG.md}} only be generated at tarball-creation time
without being committed?
# *CHANGELOG.md on main branch:* What should exist at the repository root?
** Option A: A static {{CHANGELOG.md}} with a brief description of the
{{changelog/}} directory structure and a link to
[https://solr.apache.org/docs/] for the rendered changelog
** Option B: A generated file that gets updated with each release
** Option C: No root-level {{CHANGELOG.md}} at all, only the {{changelog/}}
directory
> 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]
