Closed BenjaminRodenberg closed 3 years ago
That's a bit a philosophical question :smile:
In theory to start with a changelog only makes sense after a release, right? From a user perspective we explain the functionality of the adapter in our paper. Afterwards the changelog can explain what we gradually change from there on. In the end the changelog is where you learn about what changes from version to version, not where you learn about the basics of a software.
I see two options:
From a user perspective we explain the functionality of the adapter in our paper. Afterwards the changelog can explain what we gradually change from there on. In the end the changelog is where you learn about what changes from version to version, not where you learn about the basics of a software.
I agree with @uekerman here. Providing a changelog for v1.0.0 would be unnecessary as this is the first official release of the adapter.
- As a first entry we could mention the main features of the adapter and refer to the paper. This should be very short, we should not duplicate the paper.
This is good for someone who does not stumble on the paper but wants a brief overview of what we support. Upvote :+1:
- We leave the v1 entry completely blank.
Not sure about this. Why not put the above short description under v1.0.0
directly ?
I changed the wording to describe the "current state" rather than the "diff". What do you think?
Now that we are moving closer to a v1.0.0 release, we should also provide a Changelog.
@IshaanDesai and @uekerman any important changes, features that we should include in the Changelog? What should we do about features that were introduced much earlier? Example: The major design overhaul of the API looks to me a bit funny, if the API is never mentioned in the changelog before.