Multi-laptop naming scheme for build files

Martin Langhoff martin.langhoff at
Thu Mar 15 11:26:02 EDT 2012

On Thu, Mar 15, 2012 at 11:06 AM, Daniel Drake <dsd at> wrote:
> I'm not personally convinced that these are hard requirements, at
> least the first one.

Well, we switched streams for arm builds at least once (maybe twice)
so in the last ~12 months, there are two "os30 for arm" builds. Only
yesterday I came across a year-old email (or trac update) reporting a
problem on the f12 or f13 "os30".

> something we could accomodate. The custom stream can already be added
> at any point in the string by deployments.

So on this point, as you'd be addign support in OOB for this, I want
the custom stream name to be "part of what you do" as a custom
deployment, to gently guide them to set it...

> 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.

Sounds great to me.

> 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?

Hmmm. Maybe we can "shift our window" a bit, and drop the decade to
pick up the major release.

So 12.1.x ==> 21, and 12.2 ==> 22

> We will hit 4-digit build numbers at some point

Only for official builds, and there we are not following this scheme;
and if we do switch to follow this scheme then I expect official
builds to follow the numbering sequence.

so _if_ we switch official builds to this scheme, I'd expect for example

  21098o1.zd4 <== last dev build of the 12.1.0 series
  21099o1.zd4 <== official build , or maybe change "o" for "os" so 21100os1.zd4

As we reset the counter on a per-stream basis, it's unlikely we'll do 4 digits.

> 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...)

Ok - we're in agreement here.

> 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),

That definitely needs a build number, because deployments will spin
several builds based on 883.

I don't like this approach so much. I think the "base stream" is
better than the nominal "official base build". For example, it
accommodates the "early" build prepared by Nicaragua for 1.75 mfg.

These are awkward conditions that in a perfect world wouldn't happen,
but they do, and we're better prepared to handle them looking at the


 martin.langhoff at
 martin at -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first

More information about the Devel mailing list