CHANGELOG requirement

[wusatosi]

Currently including changelog is a requirement:

beman/docs/BEMAN_STANDARD.md

Lines 114 to 116 in 40b4984

	**[TOPLEVEL.CHANGELOG]** REQUIREMENT: There must be a `CHANGELOG.md` file at the repository's root
	that describes the high level changes in each version of the library (e.g., library status change,
	new paper implementation addition, paper implementation removal etc).

The basis of this item (PR #83) comes from weekly sync Dec 23, the meeting minutes was:

[Lead 1]: Can we leave a trace for the previous status? If yes, then we can clearly deduce the quality of the library. That would solve my concerns from last meeting.
[Member 1]: I had a similar thought. Maybe we could keep a history of the states. I’m okay to add that. This would be a table.
[Lead 1]: There’s value in seeing if a library is fully developed, even if it is retired. There is a different implication. It is useful information about whether they should be pulled into a company or not. It doesn’t need to take a lot of space. I don’t feel strongly about it.
[Member 1]: I agree that a ChangeLog would simplify the complexity and it is something we need for other bits as well for, e.g., packaging. If people are happy, I’d be happy to put information like this in the changelog and have one line in the readme.
ACTION: [Member 1], add recommendation for a changelog & link it to the beman maturity model.

Seems like, from the action item, we agreed on including changelog as a recommendation, but here it is a requirement.

This change is not well received when this is merged, and listing it as a recommendation instead is explicitly called out by a lead.

Meeting minutes Jan 13th:

Update: PR merged!

[Member 2]: Don’t like changelog.
[Member 3]: Can automate changelog updates.
[Member 1]: Only few bits need to be added in CHANGELOG - e.g. previous library status.
[Lead 1]: A way to signify development was completed but was discarded due ISO abandon in the latest stages. I would like to look at a changelog with highlevel information / changes.
[Member 2]: Remove this rule from the standard.
[Lead 2]: It should be a recommendation.
Action: Post a topic.

I don't see a discourse topic on this with search term changelog, and this is something we may need to resolve.

Edit: This is a process issue, so I have masked out the name.

[wusatosi]

In #87, PR explicitly specifies that this is still a requirement.

Update The Beman Standard to specify that the changelog file should contain only high level changes, as discussed per our weekly sync (2025-01-13)

New status:

CHANGELOG is still a REQUIREMENT. Motivation: README.LIBRARY_STATUS is a requirement, and if we want to enforce keeping history of all previous status values in the CHANGELOG, we need to have it present. I'm OK to convert both rules (+ all other related changelog rules) into recommandation, but we miss the "preserve history" point.
CHANGELOG states only to add high level events, not commit by commit logs.

This outcome is not evident at all from meeting minutes, minutes shows a fairly contested space with clear request to delegate the discussion to discourse, while in the PR it is provided as if it has reached a consensus with an agreed upon motivation. It is unclear if this is the PR author's personal opinion or an undocumented consensus.

Edit: New status here may mean new status after the sync, the origin of this "new status" is undocumented. This section was added later on.

[JeffGarland]

We may need to discuss again. I personally would prefer this be a recommendation. In part I think that should be the case because repos will exist for extended periods without a release. Still, this isn't a deal breaker one way or the other.

[wusatosi]

We may need to discuss again. I personally would prefer this be a recommendation. In part I think that should be the case because repos will exist for extended periods without a release. Still, this isn't a deal breaker one way or the other.

I was curious on the discussion about including changelog and their rational, now I am more fascinated by all the breadcrumb trails everywhere.

Edit: I don't think exploring a previously made decision should be this cryptic, I will bring this up at next sync.

[neatudarius]

Edit: I don't think exploring a previously made decision should be this cryptic, I will bring this up at next sync.

It may be a simple mistake or misinterpreted action from my side. I'm ok to convert it to recommendation.

@JeffGarland , @wusatosi , would that be acceptable? I would like to not spam again the meeting with huge number of topics.

@inbal2l , you were the person most interested about having a place for keeping history of library maturity model inside a repo. You ok converting it to recommendation?