You also need to highlight any breaking changes that come with a major release.
If you release a new major version (first number in semantic versioning), users wishing to upgrade will be viewing the change log to find out if there was a breaking change that affects them.
I generally split change logs into these headings:
Good suggestion, I wanted to mention this, but forgot to get around to it when attempting to avoid a discussion on version numbering and especially semantic versioning, so it is clearly missing from the blog post.
I have observed a lot of different versioning schemes so you cannot necessarily rely on semantic versioning, where this is implicit in the usage pattern. This does however underline the importance of emphasising breaking changes in your change log, no matter the versioning scheme used.
Thanks for the comment and feedback
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You also need to highlight any breaking changes that come with a major release.
If you release a new major version (first number in semantic versioning), users wishing to upgrade will be viewing the change log to find out if there was a breaking change that affects them.
I generally split change logs into these headings:
Good suggestion, I wanted to mention this, but forgot to get around to it when attempting to avoid a discussion on version numbering and especially semantic versioning, so it is clearly missing from the blog post.
I have observed a lot of different versioning schemes so you cannot necessarily rely on semantic versioning, where this is implicit in the usage pattern. This does however underline the importance of emphasising breaking changes in your change log, no matter the versioning scheme used.
Thanks for the comment and feedback