Changelog Design

[Ranchhand87]

Re: #32

[aleeusgr]

Looking for answers in discussions here, here and here I find that the answers are found typically in the process of developing the software in a repo, as the idea of a changelog was tied to the idea of a version, which in it essence relies on what we mean by state. More concretely, decisions around changelogs rely on what people mean by a release.

I am looking at https://pvp.haskell.org/ , but it is "package versioning policy" where we are looking for a "working group versioning policy". The goal of the Haskell PVP is to provide a formal specification for version numbers to make it possible to specify version bounds for dependency management.

What does dependency management means within the context of a working group?
What would goals for a working group versioning policy be?
What people mean by core aspects of a working group?
How do we define state of a working group?
What would a represent a breaking change, a major change, a minor change?

[aleeusgr]

Recalling the ESSIF framework it seems to fit our needs but it will take time to adopt it. We should keep it in this discussion for reference improving the WG changelog convention in the future.

scalable and interoperable infrastructure that businesses can use very easily for negotiation and execution of (business) transactions with other organizations and individuals alike.

It views itself as an ecosystem of parties that specify, develop, experiment with and validate technological and non-technological (e.g. governance) means that support people, businesses and governments (parties) to think about, design, adapt, and operate their (information) processes such that they can negotiate and conduct business transactions with one another using the electronic support

This pattern captures the essence of how things are done. It answers questions such as: "Who/what does things?", "How are their actions being guided/controlled?", "Who controls whom/what?", "Who/what may be held accountable?".