[Change Proposal] Release package spec code independently to package spec versions

[jsoriano]

Background

Package Spec releases currently consist on closing at least one GA version in the changelog, and pushing a new tag with this version, pointing to the change where the version in the changelog is closed.

This couples the release of any change in the repository to releasing new package spec version.

This has some problems, it forces the creation of many versions that would be probably unneeded, and to balance this, it may delay the release of code changes or spec fixes.

If we would decouple tagging from spec releases, we could make more releases without creating more spec versions, for example:

• Releasing fixes that would apply to already existing versions of the spec.
• Release changes in the Go code that is used by other tools.

For example, the following fixes, released as part of 3.5.1 and 3.5.2 apply to previous versions, and could have been released independently, without releasing new spec versions:

• Fix template path validation including linked files #1009
• Input packages don't require to define fields #994

Another case is when we release two versions at the same time, that leads to tag the same changeset with multiple commits, as happened with 3.4.2 and 3.5.0 (#979).

Proposal

Start tagging versions in the repository independently to package spec versions.

This requires two main changes:

• New tags for the repository.
• New structure for the changelog.

New tags for the repository

They still need to follow semantic versioning as this is what Go modules expect, so we will need to think what to do.
We could use build metadata (v1.2.3+build) or prerelease labels (v1.2.3-prerelease), but they are intended for something different.
Another option would be to release a new major, and just start using minor versions to tag the code, independently of the spec versions. We would use for example v4.0.0 as first tag of this model, even without releasing any new spec version. Then we would keep using semantic versioning as usual for the code in the repository.

New structure for the changelog

A new changelog would be started that would refer spec versions as features. So we would have entries like the following:

v4.1.0
* Spec version 3.6.0 released as GA (...).
* SLO definitions moved to new 3.7.0 spec prerelease.

v4.0.0
* Input packages using spec version over 3.5.0 don't require field definitions (https://github.com/elastic/package-spec/pull/994).
* Fix validation of template_path (https://github.com/elastic/package-spec/pull/1009).

The exact format would need to be discussed.