The right answer to the naming question depends on the meta-question of "what will we be releasing".
Are we going to continue down the path of bundling the OS and the activities into one giant release wad, or will we split out the separate components (OS, sugar, core activities) and release them on separatel schedules? The "one giant wad" approach allows coordination between the components, making it possible to do "flag day" changes. But it also makes it likely that releases will drag out indefinitely. Ultimately, I think we will need to consider the components separately, at least for some minor releases. That being the case, the naming scheme needs to identify the component. OLPC-<Component> <Generation> <Ordinal> <Component> is, e.g., OS or Sugar or Activities <Generation> changes on "flag day" releases that make coordinated changes across all components <Ordinal> is 1,2,3,... incrementing on every individual component release, not coordinated across components. Walter Bender wrote: > I think we are all in complete agreement re predictable release > schedules. It is the naming scheme we are struggling with. > > -walter > > On Tue, Apr 8, 2008 at 12:58 PM, Kent Loobey <[EMAIL PROTECTED]> wrote: > >> Here is my two cents on this subject. >> >> start-of-rant >> >> I worked for over ten years on a project that shipped software to states for >> localization and redistribution to their schools every fall. >> >> The following was true all of those years. >> >> The people that did the redistribution wanted a predictable schedule of when >> the software would arrive so that they could plan their work accordingly. >> >> The states did localization and training on each release so they needed to >> know what was going to change ahead of time. >> >> Bug fixes that fixed show stopping bugs were welcome at any time. >> >> They REALLY REALLY did not want to get releases at arbitrary times. >> >> They were much more interested in things working than in getting the lastest >> wiz-bang feature. >> >> end-of-rant >> >> It seems to me that having two releases each year would allow a region to >> select the ONE that ties into their new school year the best. To avoid use >> of any one calendar the ship dates could be on the solstices. >> >> >> _______________________________________________ >> Devel mailing list >> Devel@lists.laptop.org >> http://lists.laptop.org/listinfo/devel >> >> > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
