[
https://issues.apache.org/jira/browse/SOLR-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18030989#comment-18030989
]
David Smiley commented on SOLR-17619:
-------------------------------------
bq. that unreleased folder on the main branch will be very big
I'd be surprised if we ever exceed 100 entries. And even then, I don't see why
we should care.
bq. impossible to see from the file name where it will end up
This is true for change entry files, which are by definition, non-released. To
me, this is not a significant benefit. The info could be wrong (not *yet*
backported; forgotten), albeit unlikely. If someone wants to know where a
merged yet non-released issue has landed, look in JIRA. Probably you'd
specifically just want to know about if it was merged to the previous branch
(today that means to branch_10x), you could look there easily. Or search the
other branch's git log, which I do frequently today via my IDE from any
checkout/worktree. FWIW I keep a git worktree of the major branches on my
machines as well.
I think there's a *very* strong allure of the PR & it's change entry having
absolutely no version aspects in its contents or placement whatsoever. I don't
need to embed such a decision when creating the PR; potentially changing my
mind by the time of merge. The PR, being unentangled with versions, means I
can apply it to whatever branch (forward / back port) without mucking with
versions, and can even apply it to a fork at a company that has forks,
likewise. Reverting and latent decisions of also needing to add to other
branches can be done without mucking with versions (no moving of change
entries). It's simple to see an "unreleased/" (plainly; no version) on all
branches to know what I'm seeing -- no exceptions / variations to it.
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.
Of course, we can do almost anything. But why should we *not* keep it as
simple as I describe? I acknowledge above being able to see the apparent
intentionality of where a change goes. I could also see we might want it to be
easier to see what changes on main branch specifically are *not* backported. I
think that can be done by JIRA fixVersion = main. We resolving issues, we
should only use the lowest release version; not all branches (I've been doing
this always but not everyone does). We could also consider writing a script
that works with changelog plugin to take the directory difference between main
& branch_10x to generate an on-the-fly changelog to view. {{git diff-tree
--no-commit-id --name-only --diff-filter=A apache/branch_9x HEAD --
changelog/unreleased}} would be a part of that solution; perhaps the entire
solution if you just want to view a list of file names to see how many are
there.
> 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]
