Release policies and their implications for versioning

[dirkhh-cf]

Proposed starting point for the policy

Releases and their content are directly correlated to the versioning

• each repo needs to follow a well defined versioning methodology (either PVP or SemVer)
• date-based versioning should be avoided; if that's not possible, it still needs to be extended to allow for patch releases
• a release that includes breaking changes (any breaking changes) must have a new major version (implemented according to PVP or SemVer)
• as a result, a bug fix release must not include any breaking changes

Maintain bug fix releases for at least the last stable release, ideally for two back releases

• a bug fix release is indicated by a new patch level and only fixes bugs
• it may include other, closely related changes that are required or highly correlated to the bug fix
• if a bug fix is released together with new features (or with a breaking change), this must be done as two releases: one with just the bug fix as patch level update for the last stable release, and a new (stable?) release with a new minor or if necessary major version

[michaelpj]

I think there are a few things here:

1. Versioning scheme and the meaning of versions (including patch versions)
   • That should be covered by https://github.com/input-output-hk/cardano-engineering-handbook/issues/14: either of the structured version schemes being proposed there insist on accurately reflecting types of change in the version number.
2. A proposal that we should have blessed "stable" releases, and that those should have a bug support window in which we backport fixes.

I think 1 we can tackle in the other issue, 2 seems ambitious to me at this point. I would like to see any project of ours adopt such an approach before we try and roll out out more widely. The goal is to try and write policy that mostly matches what we actually do, rather than having something aspirational that isn't followed. And we are a long way from following the second part. The first part is hopefully within reach, though.

[dirkhh-cf]

I understand the sentiment. But I politely disagree. I think a handbook should describe what the teams should do. And I am flabergasted by the idea that a project that is used to manage "real money" would release a critical bug fix together with a breaking change.

But then again - I'm just the outside open source dude and don't work at IO - so feel free to ignore my input.

[michaelpj]

I would like to get there, I just think we should get there in smaller steps :)