os-builder: could we roll a 1.3.1?

Daniel Drake dsd at laptop.org
Thu Mar 10 15:56:18 EST 2011


On 3 March 2011 22:21, Martin Langhoff <martin.langhoff at gmail.com> wrote:

>  - Very clearly, the changes I am proposing do _not_ affect the build
> of 10.1.3 -- they don't change the .ks file prep, or anything after. I
> am happy to run test to verify

Sorry for the delayed response, I haven't had much OLPC time this week :(

I agree that all your changes are safe. I was just worried about the
general idea of allowing further commits after a released build. But
this is not the first time I have come across the kind of thing you
have identified.

So I'm thinking we should agree and document that small, safe changes
can be made (as long as its clear that the default configuration
builds won't be affected at all), and switch the wiki to recommending
version (e.g.) "1.3" for 10.1.3, rather than specifying the exact
version 1.3.0. It is then clear that the official OLPC OS release was
built using the x.x.0 version, but the wiki would suggest that users
and deployments go for the newer one (1.3.1) allowing for fixes like
the ones you have identified, without worry that the default build
output would change.

what do you think about the attached change?
-------------- next part --------------
diff --git a/doc/README.devel b/doc/README.devel
index 3b2d456..5cb3c9b 100644
--- a/doc/README.devel
+++ b/doc/README.devel
@@ -265,8 +265,8 @@ When releasing an official OLPC OS build, you should do the following:
  - Make and test the build
  (assuming test success...)
  - Bump olpc-os-builder version number
- - Modify config to set suggested_oob_version in [base] to the new version
-   number
+ - Modify config to set suggested_oob_version in [base] to the first two
+   components of the new version number (e.g. 1.3)
  - Delete [base].official setting from config
  - Save config in examples/ directory with appropriate name
  - Tag and release new olpc-os-builder
@@ -283,3 +283,43 @@ was made. If deployments try to replicate the same build but use a different
 oob version with different module code, then they will end up with the
 undesirable result of an OS build that is somewhat different from the official.
 
+
+== VERSION NUMBERS ==
+
+The olpc-os-builder version number has 3 components, e.g. v1.2.3
+
+The first component relates to the version of Fedora the tool works with.
+It must be incremented every time the tool is modified to produce builds based
+on a new version of Fedora.
+
+The second component refers to the minor release of the official OLPC OS
+release that the tool was used to build. It must be incremented when starting
+work on a new minor release. For example, v1.2.0 was used to build
+OLPC OS 10.1.2, this was incremented to v1.3.0 when development started on OLPC
+OS 10.1.3.
+
+The third version component starts at 0 for a given OLPC OS release. The
+official OLPC OS release is always made with 0 as the third component
+(e.g. v1.3.0). If new versions of olpc-os-builder are released that still
+build the same OLPC OS release, this number gets incremented (see below for
+more information).
+
+
+== CODE FREEZES ==
+
+By definition, OLPC OS releases are always made with olpc-os-builder releases
+that have 0 as the 3rd version component (e.g. v1.3.0). As an aim of the tool
+is to allow for exact reconstruction of OLPC OS releases into the future,
+the branch where this olpc-os-builder was made automatically goes into a code
+freeze.
+
+In this frozen state, further commits can be made, but only for small patches
+which undoubtedly do not affect the build output when the standard OLPC OS
+configuration is used. The equivalent functionality or fixes must already be
+present in the master branch. If there is any doubt as to whether the change
+would affect the standard build output, it is not applied.
+
+Examples of commits that are permitted are fixes to bugs that prevented the
+build tool from running at all under certain environments, small changes to
+modules not used by the official OLPC OS configuration, etc.
+
diff --git a/osbuilder.py b/osbuilder.py
index b8ee3cb..ef5bac8 100755
--- a/osbuilder.py
+++ b/osbuilder.py
@@ -289,10 +289,10 @@ class OsBuilder(object):
 
         if self.cfg.has_option('global', 'suggested_oob_version'):
             suggested = self.cfg.get('global','suggested_oob_version')
-            if suggested != VERSION:
+            if self.suggested_mismatch(suggested):
                 print
                 print "WARNING: The build configuration you are using suggests that"
-                print "olpc-os-builder version v%s should be used." % suggested
+                print "olpc-os-builder version v%s.x should be used." % suggested
                 print
                 print "You are using v%s" % VERSION
                 print
@@ -317,6 +317,11 @@ class OsBuilder(object):
 
         self.read_config()
 
+    def suggested_mismatch(self, suggested_version):
+        # we only compare the first two version components
+        current_version = VERSION.rsplit('.', 2)[0]
+        return current_version != suggested_version
+
     def get_ks_file_path(self):
         return os.path.join(self.intermediatesdir, 'build.ks')
 


More information about the Devel mailing list