You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In anticipation of the versioning guidelines from Commonalities there should be a CHANGELOG.md within the project.
Will generate an initial one from the release descriptions of v0.1.0 and v0.8.0.
Going forward a new release could be discussed and agreed by a pull request to the CHANGELOG.md. The merge commit of this pull request will be then tagged as the release (not for v0.8.0 as we are already beyond that point).
The text was updated successfully, but these errors were encountered:
I just commented on the PR, but I copy the same here. I'm OK with taking that changelog from releases for the current status of the project, but we should follow the changelog template proposed in commonalities at some point, when the API is mature enough and we have to highlight the relevant changes between versions of the spec.
@jlurien yes, that is more or less the outcome of the Github release feature, content generated there + notes in beginning - chore or similar PRs. I agree to sort the changes going forward in categories, but we need also improve the information within the PRs, e.g. with a (simple) template which might also allow to use tooling to reduce the work in release process.
In anticipation of the versioning guidelines from Commonalities there should be a CHANGELOG.md within the project.
Will generate an initial one from the release descriptions of v0.1.0 and v0.8.0.
Going forward a new release could be discussed and agreed by a pull request to the CHANGELOG.md. The merge commit of this pull request will be then tagged as the release (not for v0.8.0 as we are already beyond that point).
The text was updated successfully, but these errors were encountered: