Skip to content

RedtamarinVersion

Jump to bottom Edit New page
Zwetan Kjukov edited this page Jan 6, 2016 · 8 revisions

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.
Add a custom footer
Add a custom sidebar
Clone this wiki locally