RedtamarinVersion

Redtamarin Version

Since the v0.4 branch we changed the way redtamarin is versioned, here all the details.

History

Here, as an example, how you would version with subversion
version = major . minor . build . revision where major.minor is the version of your program
build indicate a fix or patch
and revision is the revision number of subversion

The above was not working for us for different reasons

• revision works only with subversion, not others like hg, git, etc.
• it's pretty hard to embed the "right" revision in the final executable
• we needed to be able to iterate a lot (eg. produce a lot of versions)
  without "exploding" the version number major.minor

So we decided to use version tagging
version = major . minor . (serie | cycle | build)
where major.minor is the version of the program
followed by a tag eg. (serie | cycle | build)
where serie is a single digit from 0 to 9
cycle a letter from A to Z
and build is a triple digit from 000 to 999

With that we had few releases

• our old version was 0.3.2
  so we decided to start from 0.4
  and R for redtamarin as the cycle
• 0.4.1R000
  900+ iterations
• 0.4.1S540
  new cycle, 500+ iterations
• 0.4.1T000
  new cycle
• 0.4.1T174
  170+ iterations

This version tagging, inspired by Apple iOS version build, was working but we made a little mistake and now we need to correct it.

Now, we use a mix of semantic versioning and version tagging.

Semantic versioning works this way
version = major . minor . patch
with major version when you make incompatible API changes
minor version when you add functionality in a backwards-compatible manner
and patch version when you make backwards-compatible bug fixes

Our mistake was to forget to use a patch version, but not really to follow semantic versioning, our problem is related to binary distribution.

We want to distribute debian packages eg. .deb
this will not work redtamarin_0.4.1T174.deb
we need something like redtamarin_0.4.1.deb

Here how we parse semantic versioning

var re:RegExp = /\bv?(?P<major>[0-9]+)\.(?P<minor>[0-9]+)(?:\.(?P<patch>[0-9]+))?\b/;

it will work with the following

• 1.2
• 1.2.3
• v3.4.5
• 10.20.300
• 4.0.567
• etc.

Our Version

Our versioning is now the following
version = major . minor . patch . (serie | cycle | build)
with major . minor . patch using the semantic versioning
and (serie | cycle | build) using version tagging

But we will not completely follow semantic versioning because our major version is 0 which means we are still deciding on core design of the API and other behaviours, and for that we still need to iterate a lot.

When redtamarin will reach v1.0.0 we will then fully apply semantic versioning.

Here how we parse our version

var re:RegExp = /\bv?(?P<major>[0-9]+)\.(?P<minor>[0-9]+)(?:\.(?P<patch>[0-9]+))?(?:\.(?P<tag>[A-Z0-9]+))?\b/;

it will work with the following

• 1.2
• 1.2.3
• v3.4.5
• 10.20.300
• 4.0.567
• 0.4.0.1
• 0.4.0.1A
• 0.4.0.1A123
• etc.

And here how we parse the tag

var re:RegExp = /^(?P<serie>[0-9])(?:(?P<cycle>[A-Z]))(?:(?P<build>[0-9]+))$/;

see

• Wikipedia - Software versioning

• Semantic Versioning 2.0.0

• Why Semantic Versioning Isn't

  If at this point you're hopping on one foot and saying
  — wait a minute, Node is 0.x.x — SemVer allows pre-1.0 packages
  to change anything at any time! You're right!
  And you're also missing the forest for the trees!
  Keeping a system that's in heavy production use at pre-1.0 levels
  for many years is effectively the same thing as not using SemVer in the first place.

Codename

Not a big formula yet

• while our major version is 0
• each minor version
• have a codename
• 0.4 starts with letter A

See Redtamarin Releases

We are currently developing v0.4.x with the codename Akihabara.

Releases

A release is any packaged source, documentation, executable, library, etc. that we "distribute as" or "to use with" redtamarin.

See Redtamarin Releases.

For those releases we use

• the name
  redtamarin
  • always lowercase
  • can contains a-z, 0-9 and .
• the semantic versioning
  version = major . minor . patch
  that we use as upstream_version
• the architecture
  • win32 for Windows 32-bit
  • win64 for Windows 64-bit
  • darwin-i386 for Mac OS X 32-bit
  • darwin-amd64 for Mac OS X 64-bit
  • i386 for Debian/Ubuntu 32-bit
  • amd64 for Debian/Ubuntu 64-bit
• the debian_revision
  optional uint but we could use it
  see further explanations
• an extension
  to indicate the nature of the package
  • .deb debian package
  • .pkg Mac OS X package installer
  • .exe/.msi Windows installer

The general scenario fora redtamarin release

Operating System	Bits	package name	dependencies
Windows	64-bit	redtamarin_0.4.1_win64.deb	wpkg, cygwin
Windows	64-bit	redtamarin_0.4.1_win64.msi
Mac OS X	64-bit	redtamarin_0.4.1_darwin-amd64.deb	dpkg, macports
Mac OS X	64-bit	redtamarin_0.4.1_amd64.pkg
Linux Ubuntu	64-bit	redtamarin_0.4.1_amd64.deb

Only .deb have to indicate the architecture: win64, darwin-amd64, amd64, etc.

For native packagers like .msi or .pkg the architecture is optional, but if we were to indicate it we would use only to differentiate 32-bit from 64-bit

for example:

• redtamarin_0.4.1_amd64.pkg
  we don't need to mention darwin
  as .pkg are Mac OS X only
• redtamarin_0.4.1_i386.pkg
  same, here we only indicate it
  will install a 32-bit version
• redtamarin_0.4.1.pkg
  is considered universal
  and would contain both 32-bit and 64-bit versions

Another special case is the use of the debian_revision.

Let's say we package and distribute redtamarin_0.4.1_amd64.deb
but we realise after the fact that we messed up the package somehow
then we would release an updated package redtamarin_0.4.1-1_amd64.deb
and if it is messed up again then redtamarin_0.4.1-2_amd64.deb, etc.

The important thing to remember is that the debian_revision only apply to the package structure and/or files included, either is something is at the wrong place, or missing, etc.

We never use the debian_revision to update the versioning of the binaries.

Here a timeline example

• release redtamarin_0.4.1_amd64.deb on 1st Jan 2016
• release redtamarin_0.4.1-1_amd64.deb on 2nd Jan 2016
  oups our bad we forgot to add a shell script in /usr/share/redtamarin/bin
• release redtamarin_0.4.2_amd64.deb on 1st Feb 2016 we added new features to redtamarin
• release redtamarin_0.4.3_amd64.deb on 1st Mar 2016
  we added again new features to redtamarin
• release redtamarin_0.4.3-1_amd64.deb on 2nd Mar 2016
  oups forgot to add the updated readme file
• release redtamarin_0.4.3-2_amd64.deb on 3rd Mar 2016
  oups forgot to trim the executable
  yes the size of the binaries change
  but we did not recompile them
• etc.