Skip to content

devise and document changelog policy #1125

@JedMeister

Description

@JedMeister

TurnKey should have a clearly defined policy on what should (and shouldn't) be noted in changelogs. IMO the policy should be bundled in with the TKLDev docs as it would be relevant to appliance developers and maintainers.

The current situation is quite adhoc and some consistency (both between appliances, and between releases) would be useful for end users. Having said that, I don't personally want to dictate what should or shouldn't go into a changelog, so let's have a discussion about it. Part of that discussion should be clarity on who the intended audience of the changelog is.

OTTOMH a few things that should be included in the changelogs:

  • changes to upstream version (for appliances that include 3rd party software)
  • changes to upstream install method (for appliances that include 3rd party software, e.g. tarball install, composer install, git clone install, etc)
  • specific bugfixes and feature requests which have been implemented
  • adjustments to inithooks, specifically inclusion/removal of questions/settings
  • any/all configuration changes from Debian defaults (not necessarily every specific change, but the fact that we aren't using Debian defaults - where the specifics of these changes can be found should be noted IMO)
  • changes to TurnKey packages (pkgs common to all appliances noted in core only; pkgs common to specific appliances, e.g. tkldev - in that appliance only)

Additionally, IMO we should consider having common changelog text noted somewhere in common. That way when someone updates an appliance that uses something from common they have some changelog content which can be copy/pasted.

Also relevant to #728 & #275

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions