Add semantic version numbers: Discussion

[bbros-dev]

Currently everything is latest.
We understand and don't dispute some of the the appeal of this.
In the past it has caused us more pain than it avoided.

We are considering 'jumping' to the next Debian stable series, Debian 10 - Buster.
This is likely to happen again, etc.

As dockcross image use increases it is likely that there will be build chains happy to stay on an earlier version, or that may break as toolchains move on.
We expect our builds will be such a case - latest everywhere (outside of dev and test) makes us nervous.

Is moving to versioned images something you'd consider?
If so would you want to tag the current images 1.0.0 before cutting over to Debian 10 - Buster?

[jcfr]

Is moving to versioned images something you'd consider?

Yes, may be we should simply add a line in the list of Features, what about something like this:

* Published docker image are associated with a permanent tag of the form `YYYYMMDD-SHA{7}`

Indeed, while the latest tag is updated, every version published on dockerhub is also archived with its own tag.

For example, see https://microbadger.com/images/dockcross/linux-x64 and https://hub.docker.com/r/dockcross/linux-x64/tags

[jcfr]

That said, we currently do not document which changes was introduced with which version.

May be we could introduce a CHANGES.rst file where we would add entries of the form:

* YYYY-MM-DD:
  * <imagename>:
     * Add support for ... 
     * Update xxx from yyy to zzz

[bbros-dev]

Our rule of thumb is version data must communicate useful (ideally production related) information.
20191024 vs 20200414 tells us nothing about whether it is safe to upgrade.

Example:
1.0.1 vs 1.0.12 tells us we should upgrade - expecting only fixes and no breaking changes.
1.0.1 vs 2.1.13 tells us not without further investigation and extensive testing.

Github, CircleCI etc take care of the information in the sha.

[jcfr]

I agree with you. Having semantic versioning could be helpful 👍

At that stage I don't think we have the resources to independently maintain different version numbers for each images. 😢

All of that said, if we have an automated mechanism to manage the versioning based on commit messages, semantic versioning would be much easier to implement.

Is it something you have experience with and could help implement ? 🙏

cc: @thewtex

[bbros-dev]

Agreed automated versioning is the way to go. Likewise release note creation.
Alt: refactor such that all version data comes from one source - could be harder - not yet familiar enough with the code base.

if we have an automated mechanism to manage the versioning based on commit messages, semantic versioning would be much easier to implement.

I'll see which of our scripts might fit - but refro-fiting these things is always tricky.
Expect iterations.

[thewtex]

Semantic versioning for this project is difficult due to the relationship between images, e.g. not everything actually depends on base, and changes that only impact a subset of images should not necessarily change the version of other images -- the version is not very meaningful in that case. If there is a good, automated way that semantic versioning can be handled, that will be great. ⛅ There are a wide pool of occasional contributors, and an automated versioning scheme based on commit messages or changelog's is required to keep the barrier to entry low and to prevent repeated long explanations of how to update the version.

[bbros-dev]

Closing this since we now have a setup that approximately works for us and we won't be able to spend further time on this.
Our changes will land in a PR but diverge sufficiently from what you describe to mean there is a high likelihood of rejection - we'll see ;)