Skip to content

Versioning scheme

@cattanem @clemenci it was not obvious to come up with a stack version for the patch release in !137 (merged). I know stack versions are not used for anything right now but probably we should decide on this before they are.

So far our versioning schema seems to be YYYY.MM[.MINOR] where MINOR is either an implicit 0 and thus omitted or a number that is incremented. Most stacks (e.g. sim, digi) won't have two releases in the same month, but with RTA/DPA this is pretty much a given (especially now that we've agreed to have regular bi-weekly releases).

The question is how do we extend the scheme with patch versions? Some ways I can think of:

  1. YYYY.MM[.MINOR][_PATCH] (I went arbitrarily with this for now), so e.g. 2022.12_1 for patch to 2022.12 and 2022.12.1_1 for a patch to 2022.12.1
  2. YYYY.MM[.MINOR[.PATCH]], so 2022.12.0.1 for a patch to 2022.12 and 2022.12.1.1 for a patch to 2022.12.1
  3. YYYY.MM[.MINOR[_PATCH]], so 2022.12.0_1 for a patch to 2022.12 and 2022.12.1_1 for a patch to 2022.12.1
  4. YYYY.MM.MINOR[.PATCH], i.e. always explicitly put a minor version number. This would require updating versions up to now.
  5. YYYY.MM.DD[_PATCH], YYYY.MM[.DD[_PATCH]] or other variants (which might make sense as we go for (bi)weekly releases).

Maybe this is a point we can discuss at a future PAC (even if for this MR we should choose something)