Re: Build Debate: Followup on Build Naming
On Wed, Apr 30, 2008 at 5:39 PM, Charles Merriam [EMAIL PROTECTED] wrote: After a small novel worth of posts about having time-based release numbers, the push from those that make that choice seem to be to have function based release numbers. The time-based release number was my minimum buy-in as stated, so I'll bow out of build and release problems for another year. I've given up, and I'm just calling it the August release until we decide who makes the decisions around here. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
Thanks for formalising this, I would also strongly suggest that the organisation is moved to the far right, and that we get rid of year. component major minor bugfix organisation I strongly suggest we keep the year. Yes, really, OLPC should release new software at least once per year. It should dump support for software two or more years old. It should release based on time, not feature. Also, why add a minor-minor (bugfix) number? Charles ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Thursday 10 April 2008, Charles Merriam wrote: Thanks for formalising this, I would also strongly suggest that the organisation is moved to the far right, and that we get rid of year. component major minor bugfix organisation I strongly suggest we keep the year. Yes, really, OLPC should release new software at least once per year. It should dump support for software two or more years old. It should release based on time, not feature. Also, why add a minor-minor (bugfix) number? I strongly feel that we should not put the year in releases. I personally think that we should use OLPC-Version.bugfix for the os so what has previously been called update.1 should be OLPC-2.0 any bug fixes based on this would be OLPC-2.1 etc Dennis signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Thu, 2008-04-10 at 10:32 -0500, Dennis Gilmore wrote: On Thursday 10 April 2008, Charles Merriam wrote: Thanks for formalising this, I would also strongly suggest that the organisation is moved to the far right, and that we get rid of year. component major minor bugfix organisation I strongly suggest we keep the year. Yes, really, OLPC should release new software at least once per year. It should dump support for software two or more years old. It should release based on time, not feature. Also, why add a minor-minor (bugfix) number? I strongly feel that we should not put the year in releases. I personally think that we should use OLPC-Version.bugfix for the os so what has previously been called update.1 should be OLPC-2.0 any bug fixes based on this would be OLPC-2.1 etc Dennis The question is really would the date be information that is useful. I am not sure. My feeling is that at the rate things are going with development it would not. Who cares for example if f8 came out in 2007 or 2008 and why would that be important information? -- === The means-and-ends moralists, or non-doers, always end up on their ends without any means. -- Saul Alinsky === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
2008/4/10 Martin Dengler [EMAIL PROTECTED]: How about a two digit (zero-padded) version number that started with 08? The release date is data that belongs elsewhere -- and it's not accurate, a long-term- What you need is the critical information when you are deciding whether to install/update a given release: component : What it is that I am installing. major : can I expect an API break, is there a promise of long-term supportability? minor : incremental non-breaking feature upgrade? bugfix : maturity customizer : vanilla version or the localised/contextualised one? there are many large long-lived projects using this scheme or minor variations -- and it works great. Most importantly, people understand it very well. As an example, what we know as Apache is released as: httpd-1.3.x / httpd- 2.0.x / httpd-2.2.x We have other places where we actually add value. Lets do something clear and well understood here, and move on. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
Do you expect to make a major change to the API more than once per year? Would you like major changes to the server API to release contemporaneously with other components? Do you want subtle, minor changes to the API made over a year ago to be the cause of difficult to diagnose problems? Do you want both you and customers to have a context in which only one year of development need be considered? How bad is it if all minor bug-fixes and minor API changes are given a new major version once per year? - ask interesting questions ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
Agreed. The date doesn't need to be in the build #, and only makes it longer. And I don't know how meaningful it is to have a build named OLPC -- as noted a few times, we are building more than one thing. If anything, that should be a clarifier at the end noting that OLPC was the 'customizer' of the build. SJ On Thu, Apr 10, 2008 at 11:39 AM, Aaron Konstam [EMAIL PROTECTED] wrote: On Thu, 2008-04-10 at 10:32 -0500, Dennis Gilmore wrote: On Thursday 10 April 2008, Charles Merriam wrote: Thanks for formalising this, I would also strongly suggest that the organisation is moved to the far right, and that we get rid of year. component major minor bugfix organisation I strongly suggest we keep the year. Yes, really, OLPC should release new software at least once per year. It should dump support for software two or more years old. It should release based on time, not feature. Also, why add a minor-minor (bugfix) number? I strongly feel that we should not put the year in releases. I personally think that we should use OLPC-Version.bugfix for the os so what has previously been called update.1 should be OLPC-2.0 any bug fixes based on this would be OLPC-2.1 etc Dennis The question is really would the date be information that is useful. I am not sure. My feeling is that at the rate things are going with development it would not. Who cares for example if f8 came out in 2007 or 2008 and why would that be important information? -- === The means-and-ends moralists, or non-doers, always end up on their ends without any means. -- Saul Alinsky === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ 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
Re: Build Debate: Followup on Build Naming
Redundancy is not bad. There are people who care about year (it is far easier to remember that the last time I updated was 2 years ago, than remember the build number then) and they should have something to hold on to. I vote including the year in addition to whatever else, but not using it to replace major. 2008/4/10 Samuel Klein [EMAIL PROTECTED]: Agreed. The date doesn't need to be in the build #, and only makes it longer. And I don't know how meaningful it is to have a build named OLPC -- as noted a few times, we are building more than one thing. If anything, that should be a clarifier at the end noting that OLPC was the 'customizer' of the build. SJ On Thu, Apr 10, 2008 at 11:39 AM, Aaron Konstam [EMAIL PROTECTED] wrote: On Thu, 2008-04-10 at 10:32 -0500, Dennis Gilmore wrote: On Thursday 10 April 2008, Charles Merriam wrote: Thanks for formalising this, I would also strongly suggest that the organisation is moved to the far right, and that we get rid of year. component major minor bugfix organisation I strongly suggest we keep the year. Yes, really, OLPC should release new software at least once per year. It should dump support for software two or more years old. It should release based on time, not feature. Also, why add a minor-minor (bugfix) number? I strongly feel that we should not put the year in releases. I personally think that we should use OLPC-Version.bugfix for the os so what has previously been called update.1 should be OLPC-2.0 any bug fixes based on this would be OLPC-2.1 etc Dennis The question is really would the date be information that is useful. I am not sure. My feeling is that at the rate things are going with development it would not. Who cares for example if f8 came out in 2007 or 2008 and why would that be important information? -- === The means-and-ends moralists, or non-doers, always end up on their ends without any means. -- Saul Alinsky === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ 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
Re: Build Debate: Followup on Build Naming
2008/4/10 Jameson Chema Quinn [EMAIL PROTECTED]: Redundancy is not bad. There are people who care about year (it is far easier to remember that the last time I updated was 2 years ago, than remember the build number then) and they should have something to hold on to. I vote including the year in addition to whatever else, but not using it to replace major. Do remember that the year is inaccurate and therefore misleading for anything that is in long-term-support. fooz-2006-1.3.4-australia was perhaps released in 2007. And it generates confusion - will the major number reset to 1 in 2007? The ubuntu numbering scheme causes quite a bit of confusion for example. This is not about being creative. Look at the software you use, the version scheme it uses, and whether it is clear to end users. I fully support calendar-based release schedules, but the date does not belong in the release name (except for development snapshots likw fooz-cvs20050607.tar.gz). cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
Dennis Gilmore wrote: On Monday 07 April 2008, Michael Stone wrote: cjb, cscott, and I just chatted about build names. We have absolutely no problem announcing official-703 (when candidate-703 becomes official) under whatever name seems good but we have no consensus about what that name should be. cscott proposes '8.1' on the basis that it will be our first 2008 release. mstone thought we should bake a month into the name (perhaps 2008.04 or April-2008). Scott strongly preferred to avoid baking a month designator into the name because, as best I understand, he thinks we cannot afford to ship another release until we've made 'enough' improvement in at least one of our (approximately) four networking scenarios. I like scott's proposal '8.1'. Putting a month or a season(summer/winter) there restrict us - and since we have seen that 'update.1' has taken longer than expected it would be wise not to. I honestly think we should call it OLPC 2 which matches the cvs/build tag and signifies release number 2 OLPC 1 being ship.2 then we just increment the number for each stable release. we have a development codename of joyride. we can create a name for each release. This would work for me as well - though the extra information of (year/release) is not available here. Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
Morgan Collett wrote: On Tue, Apr 8, 2008 at 9:51 AM, Simon Schampijer [EMAIL PROTECTED] wrote: Dennis Gilmore wrote: On Monday 07 April 2008, Michael Stone wrote: cjb, cscott, and I just chatted about build names. We have absolutely no problem announcing official-703 (when candidate-703 becomes official) under whatever name seems good but we have no consensus about what that name should be. cscott proposes '8.1' on the basis that it will be our first 2008 release. mstone thought we should bake a month into the name (perhaps 2008.04 or April-2008). Scott strongly preferred to avoid baking a month designator into the name because, as best I understand, he thinks we cannot afford to ship another release until we've made 'enough' improvement in at least one of our (approximately) four networking scenarios. I like scott's proposal '8.1'. Putting a month or a season(summer/winter) there restrict us - and since we have seen that 'update.1' has taken longer than expected it would be wise not to. We need to call it something while it's proposed / under development, and before we know exactly when it will ship. Some distros use codenames while it's under development, and then the final release is named accordingly. (For example, what if a release we think will come out in late 2008 slips to 2009?) Otherwise, strict time-based releases would be required (which I'm in favour of, but I don't know if that decision has been taken yet...) Morgan Good point, I think having a feature or a time based releases has a great impact on the naming. In feature based releases the naming dennis proposed (e.g. OLPC-2) would make sense to me. Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Tue, Apr 8, 2008 at 9:51 AM, Simon Schampijer [EMAIL PROTECTED] wrote: Dennis Gilmore wrote: On Monday 07 April 2008, Michael Stone wrote: cjb, cscott, and I just chatted about build names. We have absolutely no problem announcing official-703 (when candidate-703 becomes official) under whatever name seems good but we have no consensus about what that name should be. cscott proposes '8.1' on the basis that it will be our first 2008 release. mstone thought we should bake a month into the name (perhaps 2008.04 or April-2008). Scott strongly preferred to avoid baking a month designator into the name because, as best I understand, he thinks we cannot afford to ship another release until we've made 'enough' improvement in at least one of our (approximately) four networking scenarios. I like scott's proposal '8.1'. Putting a month or a season(summer/winter) there restrict us - and since we have seen that 'update.1' has taken longer than expected it would be wise not to. We need to call it something while it's proposed / under development, and before we know exactly when it will ship. Some distros use codenames while it's under development, and then the final release is named accordingly. (For example, what if a release we think will come out in late 2008 slips to 2009?) Otherwise, strict time-based releases would be required (which I'm in favour of, but I don't know if that decision has been taken yet...) Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Monday 07 April 2008, Gary C Martin wrote: On 8 Apr 2008, at 04:53, Dennis Gilmore wrote: I honestly think we should call it OLPC 2 which matches the cvs/ build tag and signifies release number 2 OLPC 1 being ship.2 then we just increment the number for each stable release. we have a development codename of joyride. we can create a name for each release. Wouldn't OLPC 2 be new XO hardware? Just a gut feeling I get – but at least there's no damn date in there ;-) the hardware is XO-1 the next revison will be XO-2 the version of the OS that we have out when the next hardware revision comes out i would hope works on both sets of hardware. even if the hardware is a different architecture then i would hope we use the same source packages for both architectures. Dennis ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Tue, 2008-04-08 at 04:34 +0100, Gary C Martin wrote: Well, if this is a democracy, of sorts, I'll stick my neck out and vote to stick with a release-703, or official-703, kind'a format. I just really, really dislike dates floating into version naming (and even worse product naming - where the goal is to make you feel out of date in time for the next hard sell). Also avoids all that, so whose calendar format/locale are we going to use in the name, what's so magical about the end of a year that we get a whole new number to release, and so what specific release version number did go out in the April-2008 build? Gary I don't know the answer but as I told Michael Stone using names like 656 together with names like update-1-703 is shear lunacy. What ever the naming scheme is it should consistent without on all levels of discussion about the build. The indication of which are ready fro prime time by using words like stable, development or unstable might be acceptable, but once it is stable the name should blend with the names of other stable builds. In case you missed it in the support group teleconference there was a suggestion to name Update-1-703, Uruguay-703. -- === I've given up reading books; I find it takes my mind off myself. === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
Is Uruguay even using 703? Peru is. Mexico probably will... Mongolia probably will... While I like the discipline that is suggested by a date scheme, it doesn't really add much real value over simply sequential numbering. We certainly should avoid using seasonal names, as that will cause hemispheric confusion. As far as a feature-based scheme, that will just increase the pressure to do an end-run around our renewed pledge to do time-based releases. I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
walter wrote: I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... as perhaps more of an outsider here, i'd say that this is not unambiguous. people with the laptops regularly refer to them as my OLPC -- perhaps encouraged by the unfortunate PC in the acronym. as for numbers: sequential is good, but starting higher than 1 might give room for adding structure later if necessary. (e.g. the 200 series of releases might be a break from the 100 series.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's degrees) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
This discussion reminds me of a favorite puzzle from Douglas Hofstadter 0, 1, 2, 3, 720!, ... That is a numbering scheme with lots of headroom. I agree that OLPC is the wrong name. There are reports that the software is now running, for example, on a Classmate PC. So any direct tie to OLPC is not necessarily appropriate. Maybe Sugar? something else? But there is not much simpler than 1,2,3... -walter On Tue, Apr 8, 2008 at 11:06 AM, Paul Fox [EMAIL PROTECTED] wrote: walter wrote: I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... as perhaps more of an outsider here, i'd say that this is not unambiguous. people with the laptops regularly refer to them as my OLPC -- perhaps encouraged by the unfortunate PC in the acronym. as for numbers: sequential is good, but starting higher than 1 might give room for adding structure later if necessary. (e.g. the 200 series of releases might be a break from the 100 series.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's degrees) ___ 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
Re: Build Debate: Followup on Build Naming
hmm, Sugar aims to be available as an alternative desktop in all kinds of linux distros, so would be a bad name for an OLPC-made distro. Tomeu On Tue, Apr 8, 2008 at 5:13 PM, Walter Bender [EMAIL PROTECTED] wrote: This discussion reminds me of a favorite puzzle from Douglas Hofstadter 0, 1, 2, 3, 720!, ... That is a numbering scheme with lots of headroom. I agree that OLPC is the wrong name. There are reports that the software is now running, for example, on a Classmate PC. So any direct tie to OLPC is not necessarily appropriate. Maybe Sugar? something else? But there is not much simpler than 1,2,3... -walter On Tue, Apr 8, 2008 at 11:06 AM, Paul Fox [EMAIL PROTECTED] wrote: walter wrote: I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... as perhaps more of an outsider here, i'd say that this is not unambiguous. people with the laptops regularly refer to them as my OLPC -- perhaps encouraged by the unfortunate PC in the acronym. as for numbers: sequential is good, but starting higher than 1 might give room for adding structure later if necessary. (e.g. the 200 series of releases might be a break from the 100 series.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's degrees) ___ 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
Re: Build Debate: Followup on Build Naming
True. How about OLPC-Fedora.1, ... -walter On Tue, Apr 8, 2008 at 11:21 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: hmm, Sugar aims to be available as an alternative desktop in all kinds of linux distros, so would be a bad name for an OLPC-made distro. Tomeu On Tue, Apr 8, 2008 at 5:13 PM, Walter Bender [EMAIL PROTECTED] wrote: This discussion reminds me of a favorite puzzle from Douglas Hofstadter 0, 1, 2, 3, 720!, ... That is a numbering scheme with lots of headroom. I agree that OLPC is the wrong name. There are reports that the software is now running, for example, on a Classmate PC. So any direct tie to OLPC is not necessarily appropriate. Maybe Sugar? something else? But there is not much simpler than 1,2,3... -walter On Tue, Apr 8, 2008 at 11:06 AM, Paul Fox [EMAIL PROTECTED] wrote: walter wrote: I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... as perhaps more of an outsider here, i'd say that this is not unambiguous. people with the laptops regularly refer to them as my OLPC -- perhaps encouraged by the unfortunate PC in the acronym. as for numbers: sequential is good, but starting higher than 1 might give room for adding structure later if necessary. (e.g. the 200 series of releases might be a break from the 100 series.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's degrees) ___ 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
Re: Build Debate: Followup on Build Naming
The prefix is much longer than the actual information that the name is supposed to provide ;-) p. Walter Bender wrote: True. How about OLPC-Fedora.1, ... -walter On Tue, Apr 8, 2008 at 11:21 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: hmm, Sugar aims to be available as an alternative desktop in all kinds of linux distros, so would be a bad name for an OLPC-made distro. Tomeu On Tue, Apr 8, 2008 at 5:13 PM, Walter Bender [EMAIL PROTECTED] wrote: This discussion reminds me of a favorite puzzle from Douglas Hofstadter 0, 1, 2, 3, 720!, ... That is a numbering scheme with lots of headroom. I agree that OLPC is the wrong name. There are reports that the software is now running, for example, on a Classmate PC. So any direct tie to OLPC is not necessarily appropriate. Maybe Sugar? something else? But there is not much simpler than 1,2,3... -walter On Tue, Apr 8, 2008 at 11:06 AM, Paul Fox [EMAIL PROTECTED] wrote: walter wrote: I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... as perhaps more of an outsider here, i'd say that this is not unambiguous. people with the laptops regularly refer to them as my OLPC -- perhaps encouraged by the unfortunate PC in the acronym. as for numbers: sequential is good, but starting higher than 1 might give room for adding structure later if necessary. (e.g. the 200 series of releases might be a break from the 100 series.) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's degrees) ___ 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 -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Tue, 2008-04-08 at 10:38 -0400, Walter Bender wrote: Is Uruguay even using 703? Peru is. Mexico probably will... Mongolia probably will... Ok, maybe it was Mexico-703 but for reasons you state below that is the wrong way to go. OLPC-1, OLPC-2 , etc. sounds good to me. While I like the discipline that is suggested by a date scheme, it doesn't really add much real value over simply sequential numbering. We certainly should avoid using seasonal names, as that will cause hemispheric confusion. As far as a feature-based scheme, that will just increase the pressure to do an end-run around our renewed pledge to do time-based releases. I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... -walter -- === I don't know what Descartes' got, But booze can do what Kant cannot. -- Mike Cross === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
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
Re: Build Debate: Followup on Build Naming
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
Re: Build Debate: Followup on Build Naming
On Tue, Apr 8, 2008 at 11:38 AM, Walter Bender [EMAIL PROTECTED] wrote: As far as a feature-based scheme, that will just increase the pressure to do an end-run around our renewed pledge to do time-based releases. I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... I generally agree but rather than just incrementing numbers, we can use the opportunity to use it to communicate api, stability and feature deltas. After having worked in projects with many schemes, I find that the best communicator is a 3-part release name x.y.z where... - X is the major release name. Many projects stay in 0 until the first feature-complete/stable-api release comes out the door to claim 1. - Y is the minor feature incremental version - Z is the bugfix level So - 0.3.2 means we are on our way to feature-complete, this is the 3rd add-feature release, 2nd bugfix release - 1.0.4 is the release you want to put on machines in a country with areas so remote that you can only visit for an upgrade every 2 years - 1.5.0 means we are on a stable api, 5th feature release, just issued. Conservative people may wish to wait until 1.5.2 for example, unless something in the 1.5.0 changelog is a must have feature. - 2.0 means some APIs have changed, your Sugarized app is very likely to break. While we crank out builds and while in development we can call them anything, the important thing is the label on the release. It is the most succint means of communication with decision-makers, big and small. As such it should be a clear indication of what kind of things I'll find in the changelog, specially for those users that will not read the changelog. cheers, martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
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
Re: Build Debate: Followup on Build Naming
Actually, it is a bit more complicated; whether we should reflect this in numbering, is, however, less clear to me. We have network protocols in the presence service we depend on, and which fundamentally affect interoperability between applications (flag days). I also posit we're very likely to have to face at least one more flag day before we reach long term stability in these protocols. Changes to these protocols *may or may not* involve binary changes to activities; sometimes these will, and sometimes libraries may hide them and they not be visible to the activities (though very visible to the person using the aggregated system). So since this seems to be a long winded discussion, I wanted to point this out; even if I don't have a proposal for a numbering scheme. - Jim On Tue, 2008-04-08 at 14:30 -0300, Martin Langhoff wrote: On Tue, Apr 8, 2008 at 11:38 AM, Walter Bender [EMAIL PROTECTED] wrote: As far as a feature-based scheme, that will just increase the pressure to do an end-run around our renewed pledge to do time-based releases. I'm in favor of Dennis's suggestion. OLPC-1; OLPC-2, ... It is simple and, I argue, unambiguous. The hardware is XO-1, XO-2... I generally agree but rather than just incrementing numbers, we can use the opportunity to use it to communicate api, stability and feature deltas. After having worked in projects with many schemes, I find that the best communicator is a 3-part release name x.y.z where... - X is the major release name. Many projects stay in 0 until the first feature-complete/stable-api release comes out the door to claim 1. - Y is the minor feature incremental version - Z is the bugfix level So - 0.3.2 means we are on our way to feature-complete, this is the 3rd add-feature release, 2nd bugfix release - 1.0.4 is the release you want to put on machines in a country with areas so remote that you can only visit for an upgrade every 2 years - 1.5.0 means we are on a stable api, 5th feature release, just issued. Conservative people may wish to wait until 1.5.2 for example, unless something in the 1.5.0 changelog is a must have feature. - 2.0 means some APIs have changed, your Sugarized app is very likely to break. While we crank out builds and while in development we can call them anything, the important thing is the label on the release. It is the most succint means of communication with decision-makers, big and small. As such it should be a clear indication of what kind of things I'll find in the changelog, specially for those users that will not read the changelog. cheers, martin -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Tue, Apr 8, 2008 at 2:30 PM, Martin Langhoff [EMAIL PROTECTED] wrote: After having worked in projects with many schemes, I find that the best communicator is a 3-part release name x.y.z where... Which is what Richard is saying too, except he is clearer ;-) For builds that are custom in some way (Mexico as mentioned above), the customisation has to be last, so - 1.0.33 - 1.0.33-Mexico is clear. As for a name, I would say XOOS or XO-OS. That would make my ISOs XS-OS, which makes sense. In both cases, it is a complete OS image. Someone may package the subset that is Sugar and its apps separately. Therefore we can later say that XOOS-1.0.33 and XSOS-0.5.3 have been tested together, and that carries a ton of information that, for anyone following the versioning conventions used all around, is easy to decompress and interpret. For example, if you are using XOOS-1.0.32 with XSOS-0.5.3 you probably need not worry, and in any case, a quick read of the changelog for XOOS-1.0.33 will show you if any bugfix is desirable to you. cheers, martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Tue, Apr 8, 2008 at 2:35 PM, Jim Gettys [EMAIL PROTECTED] wrote: We have network protocols in the presence service we depend on, and which fundamentally affect interoperability between applications (flag days). I also posit we're very likely to have to face at least one more flag day before we reach long term stability in these protocols. Good point. When we know we have such incompatibilities, with the major.minor.bugfix scheme we can say: XOOS-1.1.0 onwards is not compatible with XSOS-0.5.x or earlier - you need at least XSOS-0.6.0 and people will be able to interpret that quite well. They will also be able to tell that they can go XOOS-1.9.x as far as that little x goes without breaking compat. Once we've reached 1.0.0 on both projects (the dates should hopefully converge ;-) ), we are making an implicit promise that we won't have a major flag day in the medium term -- so I don't think we should call today's XO build anything close to 1.0.0. The 1.0.0 should be the release we stay backwards compatible with for a long time, and we should pile up flag-days and unleash them unto the world the day we hop to 2.0.0. (I suspect this will be hard and impossible to do 100%) cheers, martin -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
Perhaps it would be better to use a letter instead of a number for the generation code (major release). When confronted with a string of several numbers, the human mind tends to blank out. For some reason, letter - number - number is easier to remember and say than number - number - number . For definiteness, use US ASCII upper case. Hopefully, the generation number will change only infrequently. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Tue, Apr 8, 2008 at 7:59 PM, Mitch Bradley [EMAIL PROTECTED] wrote: Perhaps it would be better to use a letter instead of a number for the generation code (major release). When confronted with a string of several numbers, the human mind tends to blank out. For some reason, letter - number - number is easier to remember and say than number - number - number . For definiteness, use US ASCII upper case. Hopefully, the generation number will change only infrequently. That's a good point, considering that I've heard people talk about Ubuntu 7 or 7.1 when the version numbers are actually 7.04 and 7.10. People are familiar with the decimal system, but seven point ten makes no sense to them. Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
Here's may proposal:
OLPC Year components major:minor [- special_build]
OLPC 2008 OS 1:0 - Mexico
OLPC 2009 Activity Bundle 2:14
SPE 2009 Student Bundle 1:0 - Approved by Sec. Mota
OLPC = Built by OLPC. If the Secretariat of Public Education builds a
custom, they name it SPE or anything not OLPC.
Year = The year (). This provides a simple, human readable, first
classification. It does encourage upgrading once a year and lets OLPC
easily drop support for versions two years old.
Components = The components included, e.g., School Server, OS,
Activity Bundle, Great Books, etc.
Major = Version numbers that restart every year. That is, 2008 OS
1.0 and 2009 OS 1.0 are different. As currently stated, OLPC F. is
pushing for two major updates per year 1.x and 2.x. Components
with the same major versions are generally expected to play together.
Minor = Yes, there will be patches and bug fixes. People should
decide if this should start at 0 for each {Component, Major Version}
or just for each {Component}. The latter would mean that one couldn't
tell how many patches were applied to the OS component, but would
know that 2008 OS 1:14 was built after 2008 Activity Bundle 1:13.
I'm in favor of just this latter scheme, because the shorthand 1:14
becomes unambiguous.
Special Build = A special build for a market or reason. So, - ISO
3166 CountryName or - G2G1 Build or whatever. While it may seem
redundant to the minor version, it makes it easy to parse.
People will use shorthands to describe this:
* OLPC 2008 1 means the first (April-ish) release of everything.
* OS 1:15 or 1:15 means the specific version for the current year.
* 2008 - Mexico means the build Mexico choose for the yearly deployment.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Tue, 2008-04-08 at 14:40 -0300, Martin Langhoff wrote: On Tue, Apr 8, 2008 at 2:30 PM, Martin Langhoff [EMAIL PROTECTED] wrote: After having worked in projects with many schemes, I find that the best communicator is a 3-part release name x.y.z where... Which is what Richard is saying too, except he is clearer ;-) For builds that are custom in some way (Mexico as mentioned above), the customisation has to be last, so - 1.0.33 - 1.0.33-Mexico is clear. As for a name, I would say XOOS or XO-OS. That would make my ISOs XS-OS, which makes sense. In both cases, it is a complete OS image. Someone may package the subset that is Sugar and its apps separately. Therefore we can later say that XOOS-1.0.33 and XSOS-0.5.3 have been tested together, and that carries a ton of information that, for anyone following the versioning conventions used all around, is easy to decompress and interpret. For example, if you are using XOOS-1.0.32 with XSOS-0.5.3 you probably need not worry, and in any case, a quick read of the changelog for XOOS-1.0.33 will show you if any bugfix is desirable to you. cheers, martin I guess I changed my mind the x.y.z names seem the best system of all the suggestions. -- === Never ask the barber if you need a haircut. === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Build Debate: Followup on Build Naming
cjb, cscott, and I just chatted about build names. We have absolutely no problem announcing official-703 (when candidate-703 becomes official) under whatever name seems good but we have no consensus about what that name should be. cscott proposes '8.1' on the basis that it will be our first 2008 release. mstone thought we should bake a month into the name (perhaps 2008.04 or April-2008). Scott strongly preferred to avoid baking a month designator into the name because, as best I understand, he thinks we cannot afford to ship another release until we've made 'enough' improvement in at least one of our (approximately) four networking scenarios. Please correct and debate, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On Mon, 7 Apr 2008 20:37:15 -0400 Michael Stone [EMAIL PROTECTED] wrote: cjb, cscott, and I just chatted about build names. We have absolutely no problem announcing official-703 (when candidate-703 becomes official) under whatever name seems good but we have no consensus about what that name should be. cscott proposes '8.1' on the basis that it will be our first 2008 release. mstone thought we should bake a month into the name (perhaps 2008.04 or April-2008). Scott strongly preferred to avoid Baking it? I propose Apple Pie. Next one, Blueberry. Mmmm.. baking a month designator into the name because, as best I understand, he thinks we cannot afford to ship another release until we've made 'enough' improvement in at least one of our (approximately) four networking scenarios. Please correct and debate, Michael ___ 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
Re: Build Debate: Followup on Build Naming
On Monday 07 April 2008, Michael Stone wrote: cjb, cscott, and I just chatted about build names. We have absolutely no problem announcing official-703 (when candidate-703 becomes official) under whatever name seems good but we have no consensus about what that name should be. cscott proposes '8.1' on the basis that it will be our first 2008 release. mstone thought we should bake a month into the name (perhaps 2008.04 or April-2008). Scott strongly preferred to avoid baking a month designator into the name because, as best I understand, he thinks we cannot afford to ship another release until we've made 'enough' improvement in at least one of our (approximately) four networking scenarios. I honestly think we should call it OLPC 2 which matches the cvs/build tag and signifies release number 2 OLPC 1 being ship.2 then we just increment the number for each stable release. we have a development codename of joyride. we can create a name for each release. Dennis ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Build Debate: Followup on Build Naming
On 8 Apr 2008, at 04:53, Dennis Gilmore wrote: I honestly think we should call it OLPC 2 which matches the cvs/ build tag and signifies release number 2 OLPC 1 being ship.2 then we just increment the number for each stable release. we have a development codename of joyride. we can create a name for each release. Wouldn't OLPC 2 be new XO hardware? Just a gut feeling I get – but at least there's no damn date in there ;-) Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
