search

ticketmaster / poshspec

Infrastructure Testing DSL running in Pester
MIT License
183 stars 32 forks source link

CHANGELOG #47

Closed michaeltlombardi closed 5 years ago

michaeltlombardi commented 7 years ago

This project maintains a release notes file which seems to partially be a changelog.

Expected Behavior

Users and developers should be able to review a changelog for this project which adheres to the keepachangelog format and thus meets the following criteria:

  • It’s made for humans, not machines, so legibility is crucial.
  • Easy to link to any section (hence Markdown over plain text).
  • One sub-section per version.
  • List releases in reverse-chronological order (newest on top).
  • Write all dates in YYYY-MM-DD format. (Example: 2012-06-02 for June 2nd, 2012.) It’s international, sensible, and language-independent.
  • Explicitly mention whether the project follows [Semantic Versioning][https://semver.org].
  • Each version should:
    • List its release date in the above format.
    • Group changes to describe their impact on the project, as follows:
    • Added for new features.
    • Changed for changes in existing functionality.
    • Deprecated for once-stable features removed in upcoming releases.
    • Removed for deprecated features removed in this release.
    • Fixed for any bug fixes.
    • Security to invite users to upgrade in case of vulnerabilities.

Current Behavior

The project has a ReleaseNotes file which includes some of this information already but which could be improved upon.

Possible Solution

Use the keepachangelog format and rename the release notes to CHANGELOG or keep a separate and full changelog.

Context

Keeping a standardized changelog makes it easy for people to see and understand what has happened version to version and when those versions were released.

michaeltlombardi commented 7 years ago

If desired, I can update the existing document per this standard and submit a PR.