semantic versioning for UT

[mariogrip]

With the new idea for changing up OTA process, I also want to propose new version system that makes sense.

I propose to use Semantic Versioning
https://semver.org/

This way we could completely get rid of framework and only rely on the version to describe both version and api/abi compat. It would also give you a lot more info about the version you are on example that a major bump has a much bigger change then for example patch.

MAJOR: bigger change that Breaks ABI/API
MINOR: adds backwards-compatible bug fixes, changes and functionality (may break smaller library ABI in really special cases, but this should be notified about!)
PATCH: adds backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

This would be how our different channels would look
1.6.2-beta2 -> 1.6.2-rc1 -> 1.6.2
beta -> rc -> stable

This way you would know what version becomes what, example you know that 1.6.2-rc will become 1.6.2 stable.

This fits great in with the "gotta go fast" proposal by dalton, here is an example how that would work

1 week:

• 1.5.6-devel0
• 1.5.6-devel1
• ----- / ----- Devel continues like this daily
• Last weeks rc becomes stable: 1.5.5-rc1 -> 1.5.5
• Last devel build of the week becomes rc: 1.5.6-devel6 -> 1.5.6-rc1

2 week:

• New devel version starts: 1.5.7-devel1
• Last weeks rc becomes stable: 1.5.6-rc1 -> 1.5.6
• Last devel build of the week becomes rc: 1.5.7-devel6 -> 1.5.7-rc1
• This continues weekly.

Then monthly we do a minor bump with more advances feathers.

We could also do a mix between slow and fast, where we are releasing stable monthly:
1 week:

• 1.5.6-devel0
• 1.5.6-devel1
• ----- / ----- Devel continues like this daily
• Last devel build of the week becomes rc: 1.5.6-devel6 -> 1.5.6-rc1

2 week:

• Devel continues daily
• Last devel build of the week becomes rc: 1.5.6-devel12 -> 1.5.6-rc2
• This continues weekly

Then after the month is over last weeks rc becomes stable: 1.5.6-rc1 -> 1.5.6

Examples:

xenial stable: 1.6.2
xenial rc: 1.6.2-rc0
xenial rc: 1.6.2-rc1
xenial devel: 1.6.2-devel1
bionic devel: 2.6.2-devel1

We would also make a clear build date in settings, this way we can know we are on the latest build.

[dobey]

But this is not really any different from a framework version. The real problem isn't whether or not the version referenced is ubuntu-sdk-X or just X as is proposed, but whether what's on the image will satisfy that ABI or not No "semantic versioning" proposal will solve that issue really, because we don't provide the ABI/API as something for which multiple versions can be installed.

[doniks]

@mariogrip content wise I dont have a strong opinion pro/contra, just some minor nitpicking:

most of the time you start counting at devel0, except in gotta go fast, week 2. please make it consistent.

i think your final example would be morr logical if it were

bionic: 2.3.7-devel1 because minor and patch will not be equal with xenial in general, but the label at the end will.

it would help to link the gottagofast thread

[alan_g]

@mariogrip said in semantic versioning for UT:

Last weeks rc becomes stable: 1.5.5-rc1 -> 1.5.6

I think this is confusing. I prefer the Debian scheme where 1.5.6~rc1 -> 1.5.6

[rogier.oudshoorn]

@alan_g Same here; maven versioning which i'm used to also goes from 1.5.6-SNAPSHOT -> 1.5.6 (release).

[mariogrip]

@alan_g Yes that what i meant, sorry a mistake.