Multi-laptop naming scheme for build files

[Daniel Drake]

On Thu, Mar 15, 2012 at 7:36 AM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> We also need
>
>  - a stream id - perhaps 2-digit year for the development builds
>  - a "custom stream" identifier for non OLPC builds

I'm not personally convinced that these are hard requirements, at
least the first one. Our release builds already have unique naming (in
terms of build number) because we follow an incrementing scheme - 860
-> 874 -> 883. But if you think it is worth the complication it is
something we could accomodate. The custom stream can already be added
at any point in the string by deployments.

> For development and non-OLPC builds, something like:
>
> o112001.zd4 (7 chars)
>
>  o - OS development build from OLPC
>  2 - XO-1 following OFW numbering
>  12 - 12.x.y stream
>  001 - build nr

I kind of like this, but I would position the alphabetic part to
separate two of the numbers to make it less cryptic.
e.g. 12001o1.zd4 in the above example.

This won't provide uniqueness between 12.1.0 build 3 and 12.2.0 build
3, for example, but I don't think we are shooting for perfection in
terms of conflict avoidance, right?

We will hit 4-digit build numbers at some point, so maybe that should
be "0001" above, meaning that only 1 character is left for deployment
use.

> For official signed OLPC builds, we could switch to this scheme, or
> stick to the existing one.

I don't see why we would adopt this for development builds but not
signed ones - where we would face again the annoyance of it being
possible to have XO-1.5 and XO-1.75 signed releases on the same media.
(for development builds you can just rename them or use
directories...)



Another approach would be to adjust the build tools to make deployment
releases use the same number that was used in the OLPC release build.
For example, if Peru customises build 883, olpc-os-builder would
produce pe883.img (ignoring the requirement of identifying target
laptop model just to simplify this point), and deployments would be
encouraged to stick to this convention. That way the stream can be
identified in a less complicated manner, providing more space for the
rest of the information that may need to be included.

Daniel