Skip to content

Define changelog approach / tooling #41

@felixarntz

Description

@felixarntz

As the performance plugin will be released in the WordPress plugin repository at some point (and also in general 😄), we should think about how to create and maintain a changelog for new features, enhancements, and bug fixes.

Some high level questions:

  • Should we maintain the changelog manually or through automated tooling (e.g. like https://github.com/WordPress/gutenberg/blob/trunk/bin/plugin/commands/changelog.js)? Manually is probably going to read more nicely, but it's also only maintainable to a limited degree. Potentially we could start with a manual approach, since it's hard to foresee how exactly an automated tooling approach should be structured for our purposes?
  • Do we want to have a separate changelog file (e.g. CHANGELOG.md on GitHub), have the changelog only on the release tags on GitHub, or should the changelog be within the readme.txt file (visible on wordpress.org directly)?

The decision for the latter will also tie into #40 - the readme.txt file either needs to continue the changelog itself or a link to where it is at.

Metadata

Metadata

Assignees

No one assigned

    Labels

    InfrastructureIssues for the overall performance plugin infrastructure

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions