[
https://issues.apache.org/jira/browse/SOLR-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18031054#comment-18031054
]
David Smiley commented on SOLR-17619:
-------------------------------------
bq. 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?
You describe a way to do it... perhaps how the logchange author imagines its
use. I proposed generating a changelog.md (with the logchange plugin),
deleting the released entries, and forward porting that commit. Is that
problematic / not supported?
bq. Should we generate a consolidated CHANGELOG.md file during the release?
Yes, of course. That question sounds equivalent to asking whether we should
have a changelog _at all_, and yes of course we need one at the release; so
maybe I misunderstand the question.
bq. If yes, should it be committed to the release branch (for inclusion in the
tarball) as a generated-only file (never manually edited)?
Yes, I think that, _basically_. Not sure the read-only is strict or you're
just saying that no edits would be needed/expected typically. Seems like a
little detail for later.
If we didn't commit the file; we'd have tons of changelog entries in tons of
directories without an obvious/easy way to read them quickly/efficiently. I
suppose the answer to that is a gradle task but... it seems to me needlessly
inconvenient vs simply read a file.
I'd prefer "Option B"; it's similar to what we are familiar with, and I think
it's good. I think it implies also having a changelog or changelog/unreleased
folder. IMO the CHANGELOG.md could very well go into changelog/, and perhaps
we might want to separate that at the major versions -- changelog-9x.md, ...
etc.
> 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]
