On Thu, Mar 15, 2012 at 7:36 AM, Martin Langhoff <martin.langh...@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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel