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
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
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
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
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
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
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
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
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
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
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
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)
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
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 -
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
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
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
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,
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
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
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
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
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 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
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
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
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
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
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 .
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 -
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
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
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
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
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
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
36 matches
Mail list logo
