Re: [sugar] Activity versioning schema

[Michael Stone]

On Thu, Jul 17, 2008 at 11:15:07AM +1200, Martin Langhoff wrote:
>On Thu, Jul 17, 2008 at 10:52 AM, Michael Stone <[EMAIL PROTECTED]> wrote:
>> For these reasons, in my humble opinion, choosing our software packaging
>> format and guidelines (of which version numbering is but a single
>> aspect) is NOT A TRIVIAL EXERCISE and is not as simple as picking an
>> off-the-shelf format. (I wish that the reality were otherwise).
>
>I understand the points you make, but - AFAICS - they don't have much
>bearing on versioning (by which I mean to say: the conventional
>RPM/Deb versioning scheme works fine). 

I don't care too much what names people give to activities but I care
greatly about how the software that manipulates those activities is
written -- in particular, about the way that it makes use of those
names, both internally and in the UI. Thus, while I will likely be
content with any naming convention that might be proposed, I have
serious reservations about the quality of the software that will result
from the _procedures_ being used to choose that naming convention. Hence
my request that we perform at least basic diligence in checking that the
proposed naming scheme and its intended usage in software is consistent
with our largely unwritten requirements.

> They do impact packaging, but... they are not *that* special either.

My goal is to avoid deploying short-term hacks which complicate future
work. Hacks to conventions seem particularly dangerous to me because
they're the hardest things to change if you get them wrong. 

As I said above, I will be happy if we choose to adopt an existing
naming scheme so long as that naming scheme is compatible with our
requirements and use cases. We just need to demonstrate that we are
aware of the consequences of our proposed scheme by checking that it
doesn't paint us into a corner down the road.

>> Do you require more justification?
>
>Ah well, I know notink of the XO so back to my cave where I try to
>reach my goals reinventing the _least_ wheels.

We have different resources to bring to bear on our respective tasks.

>Sorry about the noise.

I always (eventually) appreciate your input, even when I argue with you
or cut you off too quickly for want of the patience to find out where
you're coming from.

Michael
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Michael Stone]

>I fail to see what makes the XO case different from the rest of the
>software world - from the pages you link

I agree that the pages I cited presuppose that you understand how our
requirements differ from those of the rest of the world.

Some specific examples:

  - Our users often can't make informed decisions about what software
they should be running.

  - Our users probably do not have root on their machines, yet still
need to perform package-management-like tasks.

  - In addition to accepting code hierarchically from upstream
providers, we want to share code fluidly between XOs.

  - We want the software we provide to support a higher standard of
security (defined in Bitfrost) than other systems strive to provide.

  - We must attempt to minimize bandwidth usage while moving bits
around and must tolerate long networking delays.

  - We cannot rely on any established public key infrastructure to
verify the identities of code providers or the authenticity of the
code they are providing.

  - We expect users will be constantly redistributing modified versions
of software that they downloaded to their systems.

  - We expect that our user groups will, in general, NOT share common
languages with one another (or, necessarily, with us).

  - We expect that many users will be translating their own software.

  - We MAY NOT assume that users have global connectivity with which to
satisfy dependencies, verify claims about information, distribute
their work, etc.

For these reasons, in my humble opinion, choosing our software packaging
format and guidelines (of which version numbering is but a single
aspect) is NOT A TRIVIAL EXERCISE and is not as simple as picking an
off-the-shelf format. (I wish that the reality were otherwise). 

Do you require more justification?

Regards,

Michael
___
Devel mailing list
[EMAIL PROTECTED]
http://lists.laptop.org/listinfo/devel
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Wed, Jul 16, 2008 at 3:54 PM, Martin Langhoff <[EMAIL PROTECTED]>
wrote:

> On Thu, Jul 17, 2008 at 4:54 AM, Michael Stone <[EMAIL PROTECTED]> wrote:
> > What _should_ be happening in this thread is the collection of use
> > cases.
> >
> > For a "small" selection of the issues involved, please refer to
> >
> >   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1
> >   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2
>

+1 on creating use cases for activity versions.

-1 on that being necessary to resolve this particular thread (except insofar
as it makes "opaque version strings" less attractive). The security issues
are with the service ID, not the version.

...In the meantime, a simply obvious
> solution that meets our needs is standing in front of us, glowing
> warmly .
>
> grab it
>

+2
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Martin Langhoff]

On Thu, Jul 17, 2008 at 4:54 AM, Michael Stone <[EMAIL PROTECTED]> wrote:
> What _should_ be happening in this thread is the collection of use
> cases.
>
> For a "small" selection of the issues involved, please refer to
>
>   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1
>   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2

I fail to see what makes the XO case different from the rest of the
software world - from the pages you link

 - We need to identify feature vs bugfix revisions, which is something
that versioning can do

 - Keep track of whether we are opening an existing document with a
different program version, in that case, perhaps deal with
"capabilities" - this is orthogonal to versioning, and similar to the
"provides" field in deb packages.

 - If network interop between differing versions of tools is an issue,
we could recommend an on-the-wire preamble where versions and
optionally capabilities are exchanged, giving peers the opportunity to
refuse to interact. Orthogonal to version numbers, however.

These are well understood issues. Yes, we can write use cases, and
argue the business case, and define a procedure around it.

So as soon as we get our shipment of infinite time and resources, I
_promise_ I'll get on to it. In the meantime, a simply obvious
solution that meets our needs is standing in front of us, glowing
warmly .

grab it



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
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Michael Stone]

On Wed, Jul 16, 2008 at 01:16:51PM -0400, Greg Smith wrote:
> *** Salient quotes: "Each activity.info file must have a
> "activity_version" key. The version is a single positive integer.
> Larger versions are considered "newer". The value assigned to this key
> should be considered opaque to the activity; the only requirement of
> the activity is that it must be larger for new activity builds." 

In my opinion, the information quoted above is correct as of today. All
that is true beyond that is that we are designing a revision of the
activity packaging guidelines and formats.

Michael
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Greg Smith]

Hi Michael,

Thanks for the status. I wasn't asking if we have agreement. I was 
asking who will update the incorrect documentation when/if we have 
something new to say.

You seem to know the state of affairs, can you update this wiki link 
http://wiki.laptop.org/go/Activity_bundles so it does not say anything 
which is incorrect per Gary's suggestion below?

I'm trying to lay down some covering fire here so Gary makes it the door 
in one piece :-)

Thanks,

Greg S

(perhaps http://wiki.laptop.org/go/Activity_bundles *** would be a
start), so us external activity developers don't have to be part of
this bit punk talk.

*** Salient quotes: "Each activity.info file must have a
"activity_version" key. The version is a single positive integer.
Larger versions are considered "newer". The value assigned to this key
should be considered opaque to the activity; the only requirement of
the activity is that it must be larger for new activity builds." And:
"Each activity.info file must have a "host_version" key. The version
is a single positive integer. This specifies the version of the Sugar
environment which the activity is compatible with. (fixme: need to
specify sugar versions somewhere. Obviously we start with 1.)" 

 if this is incorrect, please, PLEASE (!!) remove it from the f$#
%ing bit rot wiki!


Michael Stone wrote:
> On Wed, Jul 16, 2008 at 09:10:56AM -0400, Greg Smith wrote:
>> Who can gather the consensus and take responsibility for updating the 
>> wiki if needed?
> 
> No one can, yet, because there's a real argument going on between the
> people who have to live with the versioning scheme on the infrastructure
> and security side and the people who want to use it in the UI.
> 
> In particular, there are non-trivial security issues with identifying
> activities internally with _anything_ spoofable - i.e. with any
> identifier that an activity can 'claim' without reference to some more
> primitive sense of identity (e.g. a cryptographic manifest).
> 
> Consequently, as I have claimed on the several other occasions when this
> discussion has come up, we are _not_ going to decide on an activity
> naming and versioning scheme without having written down our use cases
> and checked that the proposed design satisfies them.
> 
> What _should_ be happening in this thread is the collection of use
> cases.
> 
> For a "small" selection of the issues involved, please refer to
>   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1
>   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2
> 
> Regards,
> 
> Michael
> 
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Michael Stone]

On Wed, Jul 16, 2008 at 09:10:56AM -0400, Greg Smith wrote:
>Who can gather the consensus and take responsibility for updating the 
>wiki if needed?

No one can, yet, because there's a real argument going on between the
people who have to live with the versioning scheme on the infrastructure
and security side and the people who want to use it in the UI.

In particular, there are non-trivial security issues with identifying
activities internally with _anything_ spoofable - i.e. with any
identifier that an activity can 'claim' without reference to some more
primitive sense of identity (e.g. a cryptographic manifest).

Consequently, as I have claimed on the several other occasions when this
discussion has come up, we are _not_ going to decide on an activity
naming and versioning scheme without having written down our use cases
and checked that the proposed design satisfies them.

What _should_ be happening in this thread is the collection of use
cases.

For a "small" selection of the issues involved, please refer to 

   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_1
   http://wiki.laptop.org/go/User:Mstone/Commentaries/Bundles_2

Regards,

Michael
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Greg Smith]

+1 on Gary's comments! Hysterical and spot on. Please keep them coming 
and let me know if I can help you with your project participation.

This is an important discussion about version numbers. The most 
important part will be coming to a working assumption (albeit temporary 
and subject to change) and communicating it.

Who can gather the consensus and take responsibility for updating the 
wiki if needed?

http://wiki.laptop.org/go/Activity_bundles

Thanks,

Greg S

*
<[EMAIL PROTECTED]> Subject: Re: [sugar] Activity versioning schema 
To: Martin Langhoff <[EMAIL PROTECTED]> Cc: OLPC Development 
<[EMAIL PROTECTED]>, Eben Eliason <[EMAIL PROTECTED]>, Sugar 
List <[EMAIL PROTECTED]> Message-ID: 
<[EMAIL PROTECTED]> Content-Type: 
text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes On 16 Jul 
2008, at 00:03, Martin Langhoff wrote:
 > > On Wed, Jul 16, 2008 at 10:51 AM, Gary C Martin
 > > <[EMAIL PROTECTED]> wrote:
 >> >> Version (activity_version) is just some sortable entity to be agreed
 > >
 > > Please do read back on this - now lenghty - discussion. Unfortunately,
 > > any monotonically increasing version does _not_ work, thanks to the
 > > magic of maintenance releases. Let us bow collectively to the wisdom
 > > of distro maintainers who are smart and have been doing this job for
 > > far longer than us.
 > >
 > > In other words, let us do the same thing that rpm and dpkg do.
 > >
 > > It gives you both more expressive power, and a stupid "1.1.0.9z is
 > > older than 2.0-alpha" cmp function for whenever you need it.

OK, sorry, I've clearly accidentally wandered in to a room full of
hardcore gun toting bit heads ? I'm now backing slowly towards the
exit, my hands clearly raised. Please do be sure to post whatever (I'm
sure excellent) final outcome is, clearly and somewhere public
(perhaps http://wiki.laptop.org/go/Activity_bundles *** would be a
start), so us external activity developers don't have to be part of
this bit punk talk.

*** Salient quotes: "Each activity.info file must have a
"activity_version" key. The version is a single positive integer.
Larger versions are considered "newer". The value assigned to this key
should be considered opaque to the activity; the only requirement of
the activity is that it must be larger for new activity builds." And:
"Each activity.info file must have a "host_version" key. The version
is a single positive integer. This specifies the version of the Sugar
environment which the activity is compatible with. (fixme: need to
specify sugar versions somewhere. Obviously we start with 1.)" 

 if this is incorrect, please, PLEASE (!!) remove it from the f$#
%ing bit rot wiki!

--Gary
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Samuel Klein]

On Tue, Jul 15, 2008 at 7:03 PM, Martin Langhoff <[EMAIL PROTECTED]>
wrote:

> On Wed, Jul 16, 2008 at 10:51 AM, Gary C Martin <[EMAIL PROTECTED]>
> wrote:
> > Version (activity_version) is just some sortable entity to be agreed
>
>  In other words, let us do the same thing that rpm and dpkg do.
>
> It gives you both more expressive power, and a stupid "1.1.0.9z is
> older than 2.0-alpha" cmp function for whenever you need it.
>

Right on.SJ.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Samuel Klein]

>> Basically, there are two separate problems here,  and we should not
>>  be solving them together. One is that the latest release may not be
>> the greatest - because of bugfix releases. I agree with Eben's proposal
>> of minor version numbers as a (totally optional) solution; as long as
>> the minor/major separator is not a decimal separator (that is, [.,]), the

>> meaning is pretty self-evident. (I think that : is the best candidate, by

>> analogy with times and bible verses.)
> This is actually my primary concern.

Ditto.  I'm strongly in favor of supporting minor versions for this -- the
notion of monotonically increasing 'version' is fundamentally misleading.
Major.minor is less broken.

On Mon, Jul 14, 2008 at 6:24 PM, Eben Eliason <[EMAIL PROTECTED]>
wrote:


> On the contrary, you are missing mine.  I don't *want* this in the bundle.
>  I want this to be a sentence that can be stated, at some point following
> the release of 9.1, by a wiki page, the release notes, a tech support
> person, a friend, or the developer herself.  Nothing more.  No technical
> magic here.
>

+1

SJ
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Martin Langhoff]

On Wed, Jul 16, 2008 at 3:28 PM, Gary C Martin <[EMAIL PROTECTED]> wrote:
> OK, sorry, I've clearly accidentally wandered in to a room full of hardcore

:-) Sorry about the dry tone of my reply. I was trying, perhaps too
hard, to avoid this thread regressing into silly-land.

The current scheme is just using an int (wiki is correct here), which
is insufficient, and we need to do something smarter. But people
started reinventing perfectly good wheels, proposing that they'd be
octogonal and stuff.

Chocolate gun, see? (bites chunk off handle) hmm, tasty.


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
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Gary C Martin]

On 16 Jul 2008, at 00:03, Martin Langhoff wrote:

> On Wed, Jul 16, 2008 at 10:51 AM, Gary C Martin  
> <[EMAIL PROTECTED]> wrote:
>> Version (activity_version) is just some sortable entity to be agreed
>
> Please do read back on this - now lenghty - discussion. Unfortunately,
> any monotonically increasing version does _not_ work, thanks to the
> magic of maintenance releases. Let us bow collectively to the wisdom
> of distro maintainers who are smart and have been doing this job for
> far longer than us.
>
> In other words, let us do the same thing that rpm and dpkg do.
>
> It gives you both more expressive power, and a stupid "1.1.0.9z is
> older than 2.0-alpha" cmp function for whenever you need it.

OK, sorry, I've clearly accidentally wandered in to a room full of  
hardcore gun toting bit heads – I'm now backing slowly towards the  
exit, my hands clearly raised. Please do be sure to post whatever (I'm  
sure excellent) final outcome is, clearly and somewhere public  
(perhaps http://wiki.laptop.org/go/Activity_bundles *** would be a  
start), so us external activity developers don't have to be part of  
this bit punk talk.

*** Salient quotes: "Each activity.info file must have a  
"activity_version" key. The version is a single positive integer.  
Larger versions are considered "newer". The value assigned to this key  
should be considered opaque to the activity; the only requirement of  
the activity is that it must be larger for new activity builds." And:  
"Each activity.info file must have a "host_version" key. The version  
is a single positive integer. This specifies the version of the Sugar  
environment which the activity is compatible with. (fixme: need to  
specify sugar versions somewhere. Obviously we start with 1.)" 

 if this is incorrect, please, PLEASE (!!) remove it from the f$# 
%ing bit rot wiki!

--Gary


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Martin Langhoff]

On Wed, Jul 16, 2008 at 10:51 AM, Gary C Martin <[EMAIL PROTECTED]> wrote:
> Version (activity_version) is just some sortable entity to be agreed

Please do read back on this - now lenghty - discussion. Unfortunately,
any monotonically increasing version does _not_ work, thanks to the
magic of maintenance releases. Let us bow collectively to the wisdom
of distro maintainers who are smart and have been doing this job for
far longer than us.

In other words, let us do the same thing that rpm and dpkg do.

It gives you both more expressive power, and a stupid "1.1.0.9z is
older than 2.0-alpha" cmp function for whenever you need it.

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
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Gary C Martin]

On 15 Jul 2008, at 20:15, Eben Eliason wrote:

> On Tue, Jul 15, 2008 at 2:57 PM, C. Scott Ananian  
> <[EMAIL PROTECTED]> wrote:
>
>> 2008/7/15 Jameson Chema Quinn <[EMAIL PROTECTED]>:
>>> If you have a better idea of how Glucose should handle these issues,
>> please
>>> share it. Simplifying assumptions are good, even if they're not 100%
>> valid.
>>
>> Versions in activity.info files are either plain integers, or
>> RPM-standard version strings, with no pretense that these correspond
>> in any way to sugar major releases or anything at all, except that
>> they are ordered: if the activity updater sees that you have version
>> N, and there is a version M announced[*] as compatible with your  
>> build
>> where M > N, then it will suggest that you upgrade to M.  All other
>> meanings are encoded with other mechanisms.
>> --scott
>>
>
> How can you argue this and still argue that we can get away with  
> integer
> version numbers?  According to this logic, a when brand new  
> activity(x) for
> OS(y) is released at time (t) and a bugfix activity(x+1) for OS(y-1)  
> is
> released at time (t+1), anyone on OS(y) is going to try to update to  
> the
> "newer", larger, activity(x+1) version, with none of the new features.


Random thought, should there be an additional .info line in addition  
to version, related just to release build compatibility? Version  
(activity_version) is just some sortable entity to be agreed, integer  
is fine with me (indicating the developers best and shiniest release  
effort to date). A new .info entry for release compatibility would be  
added (release_version) holding the Sugar version last tested against.  
Sugar auto updaters would assume compatibility based on >=  
release_version. Release_versions could be (more) easily extracted for  
auto update scripts (control panel) so as to download the best and  
latest compatible code.

--Gary


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Tue, Jul 15, 2008 at 12:57 PM, C. Scott Ananian <[EMAIL PROTECTED]>
wrote:

> 2008/7/15 Jameson Chema Quinn <[EMAIL PROTECTED]>:
> > If you have a better idea of how Glucose should handle these issues,
> please
> > share it. Simplifying assumptions are good, even if they're not 100%
> valid.
>
> Versions in activity.info files are either plain integers, or
> RPM-standard version strings, with no pretense that these correspond
> in any way to sugar major releases or anything at all, except that
> they are ordered: if the activity updater sees that you have version
> N, and there is a version M announced[*] as compatible with your build
> where M > N, then it will suggest that you upgrade to M.  All other
> meanings are encoded with other mechanisms.
>  --scott
>
> I meant the UI issues, since that is what Mikus objected to. I.e., can
multiple versions of the same activity coexist on same xo? What about
journal instances from multiple versions of an activity? What can we do
concretely to try to avoid/deal with this situation?
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Tue, Jul 15, 2008 at 12:57 PM, C. Scott Ananian <[EMAIL PROTECTED]>
wrote:

> 2008/7/15 Jameson Chema Quinn <[EMAIL PROTECTED]>:
> > If you have a better idea of how Glucose should handle these issues,
> please
> > share it. Simplifying assumptions are good, even if they're not 100%
> valid.
>
> Versions in activity.info files are either plain integers, or
> RPM-standard version strings, with no pretense that these correspond
> in any way to sugar major releases or anything at all, except that
> they are ordered: if the activity updater sees that you have version
> N, and there is a version M announced[*] as compatible with your build
> where M > N, then it will suggest that you upgrade to M.  All other
> meanings are encoded with other mechanisms.
>  --scott
>
> I meant the UI issues, since that is what Mikus objected to. I.e., can
multiple versions of the same activity coexist on same xo? What about
journal instances from multiple versions of an activity? What can we do
concretely to try to avoid/deal with this situation?
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Eben Eliason]

On Tue, Jul 15, 2008 at 2:57 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> 2008/7/15 Jameson Chema Quinn <[EMAIL PROTECTED]>:
> > If you have a better idea of how Glucose should handle these issues,
> please
> > share it. Simplifying assumptions are good, even if they're not 100%
> valid.
>
> Versions in activity.info files are either plain integers, or
> RPM-standard version strings, with no pretense that these correspond
> in any way to sugar major releases or anything at all, except that
> they are ordered: if the activity updater sees that you have version
> N, and there is a version M announced[*] as compatible with your build
> where M > N, then it will suggest that you upgrade to M.  All other
> meanings are encoded with other mechanisms.
>  --scott
>

How can you argue this and still argue that we can get away with integer
version numbers?  According to this logic, a when brand new activity(x) for
OS(y) is released at time (t) and a bugfix activity(x+1) for OS(y-1) is
released at time (t+1), anyone on OS(y) is going to try to update to the
"newer", larger, activity(x+1) version, with none of the new features.

- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[C. Scott Ananian]

2008/7/15 Jameson Chema Quinn <[EMAIL PROTECTED]>:
> If you have a better idea of how Glucose should handle these issues, please
> share it. Simplifying assumptions are good, even if they're not 100% valid.

Versions in activity.info files are either plain integers, or
RPM-standard version strings, with no pretense that these correspond
in any way to sugar major releases or anything at all, except that
they are ordered: if the activity updater sees that you have version
N, and there is a version M announced[*] as compatible with your build
where M > N, then it will suggest that you upgrade to M.  All other
meanings are encoded with other mechanisms.
  --scott

[*] Announced means either published at the update_url specified in
your activity.info (working today), or broadcast on the network from
your friend or the school server or by some other mechanism (someday).

-- 
 ( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Mon, Jul 14, 2008 at 8:29 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote:

>  If, as is the current plan, multiple versions of
>  an activity can coexist on an XO, ...
> > Two use cases:
> > 1. I have a journal object. I want to choose which activity to open it
> with.
> > I am presented with a multilevel menu: the top level has all activities
> > which open the mime type, the next level has all major versions of those
> > activities, the next level minor versions, etc. If click without
> bothering
> > to move over to the sublevels, I get the default version from the
> sublevel
> > of my current menu, which is the starred version (if it exists) or the
> > highest version (applied recursively down the sublevels).
>
> I'm sorry, but my mind boggles at the thought of a four-year old
> clicking on a Journal entry and being presented with a palette of
> seventeen different versions of 'TamTam' -- so that he may choose
> which of those versions is appropriate for whatever upgrade the
> adults had made to that XO last week.
>
> mikus
>
>
This is not, of course, the default behavior - if you just "click on a
journal entry", it opens with whatever version created it, or the starred
version (if the creator version is not marked as creating incompatible
entries), whichever is more mature. All that logic happens with no need for
human interaction (and yes, we need Glucose to understand something about
versions for that to work).

Nevertheless, the behavior I described is my best understanding of the
approximate consensus of
several
discussions (+2
more) I have had on IRC about this matter. I myself would (and did)
advocate for more automatic updating, and no decision is set in stone; but
no matter how automatic and smart we make things, we are going to have to
choose at some point between having a manual fallback, or having some things
break because we don't have a manual fallback. I'd rather have the fallback,
and I think that if we do, we should be hiding it in heirarchical menus as
much as possible (so that even if you DO need the fallback and even if you
DO have 6 installed versions of TamTam, Glucose is at every moment hiding as
many of them as possible until you deliberately, by hovering, ask it to show
you more).

If you have a better idea of how Glucose should handle these issues, please
share it. Simplifying assumptions are good, even if they're not 100% valid.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Mikus Grinbergs]

 If, as is the current plan, multiple versions of
 an activity can coexist on an XO, ...
> Two use cases:
> 1. I have a journal object. I want to choose which activity to open it with.
> I am presented with a multilevel menu: the top level has all activities
> which open the mime type, the next level has all major versions of those
> activities, the next level minor versions, etc. If click without bothering
> to move over to the sublevels, I get the default version from the sublevel
> of my current menu, which is the starred version (if it exists) or the
> highest version (applied recursively down the sublevels).

I'm sorry, but my mind boggles at the thought of a four-year old 
clicking on a Journal entry and being presented with a palette of 
seventeen different versions of 'TamTam' -- so that he may choose 
which of those versions is appropriate for whatever upgrade the 
adults had made to that XO last week.

mikus


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Martin Langhoff]

On Tue, Jul 15, 2008 at 12:30 PM, Benjamin M. Schwartz
<[EMAIL PROTECTED]> wrote:
> I would be happy to whip up a universal approximate ordering for version
> strings in a few lines of Python.  My emphasis here is on _approximate_;
> nothing should depend on precisely correct interpretation of version strings.

I would say - don't, unless you are doing it for the fun of it. Steal
the RPM code - see my earlier reply to Scott as to why this is a
better idea.

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
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

-BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jameson "Chema" Quinn wrote:
> | It is desirable for Sugar to be able to compare versions and
> | guess which one is newer.
>
> "Newer" means "more recent".  If this capability is important to you, then
> we may simply include a datestamp in each bundle, separate from the
> version.  However, I do not know of any planned Sugar feature that would
> require the ability to determine which bundle was created most recently.


I misspoke. I meant, "the latest", in the same sense that Eben is using it:
the version with all relevant new feature decisions (including added and
dropped features) and bugfixes. This is not always the one created at the
latest calendar date.


>
> | If, as is the current plan, multiple versions of
> | an activity can coexist on an XO, it is reasonable to want sugar to
> present
> | these in some sane order, and possibly give hints and/or aid if the user
> | wants to update and/or garbage collect. Otherwise, we might as well just
> be
> | using activity hash, which can be calculated without being explicitly
> | included in activity.info.
>
> I favor including a version string with every bundle.  I favor displaying
> this string in places where it is needed to disambiguate multiple versions
> of an Activity.  I'm merely suggesting that the system not attempt to
> parse it.
>
> You mention ordering.  The Journal designs have long called for all
> columns to be sorted, with the user selecting the order of sorting
> precedence.  One intermediate position would be for the Version column to
> be sorted according to a best-effort ordering that attempts to do
> something sane when faced with any of the common version string
> conventions.


 Two use cases:

1. I have a journal object. I want to choose which activity to open it with.
I am presented with a multilevel menu: the top level has all activities
which open the mime type, the next level has all major versions of those
activities, the next level minor versions, etc. If click without bothering
to move over to the sublevels, I get the default version from the sublevel
of my current menu, which is the starred version (if it exists) or the
highest version (applied recursively down the sublevels).

2. I just quit an activity version which is signed (ie, not just a
development build) and is a higher number than the starred version. A dialog
pops up asking if I want to "update" to that version. If I click yes, Sugar
moves the star to the new version (freeing the older version for possible
later GC). If I choose "no", the dialog will not appear again.

(Dealing with instances associated with the old version is more complicated.
Say I have an instance from Write 50 and Write 60 is starred. I suggest that
the ideal behaviour would be to open by default with Write 60, assuming it
handles the mime type, but ask after closing if that worked; if not,
remember that Write 50 instances may be incompatible with other versions and
open them by default with Write 50 always. An instance of Write 70 should
open with Write 70. This would not change GC behaviour: you might end up
GC-ing an old version and losing access to your instances, but the old
version would be available if necessary from the backup server.)

I guess you could argue that use case 2 should offer to assist downgrades as
well as upgrades (since we would be keeping separate already-showed-dialog
metadata for each version, any version would only show the dialog once, and
that would be more likely to be when it was newer), but I think that even
then it would be useful to include the words "higher version" or "lower
version" in the dialog.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Eben Eliason wrote:
| I guess the point here is that performing intelligent string comparisons on
| several of these schemes requires parsing the string. ;)

I would be happy to whip up a universal approximate ordering for version
strings in a few lines of Python.  My emphasis here is on _approximate_;
nothing should depend on precisely correct interpretation of version strings.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh7748ACgkQUJT6e6HFtqR+PACfa4VCNDYT7iqbDyq4ER7doTbU
jCsAnAmR0TWlhah9sRG6YNx/ve9tqWT6
=CxR/
-END PGP SIGNATURE-
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 7:47 PM, Benjamin M. Schwartz <
[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jameson "Chema" Quinn wrote:
> | It is desirable for Sugar to be able to compare versions and
> | guess which one is newer.
>
> "Newer" means "more recent".  If this capability is important to you, then
> we may simply include a datestamp in each bundle, separate from the
> version.  However, I do not know of any planned Sugar feature that would
> require the ability to determine which bundle was created most recently.


I'm not sure that has to be what we mean by "newer", and if it is, we need
to find a better word.  Dates are *not* the criteria we want for newness.
Code maturity is closer to the intended meaning, and I think is the newness
that Jameson is also referring to.

>
> | If, as is the current plan, multiple versions of
> | an activity can coexist on an XO, it is reasonable to want sugar to
> present
> | these in some sane order, and possibly give hints and/or aid if the user
> | wants to update and/or garbage collect. Otherwise, we might as well just
> be
> | using activity hash, which can be calculated without being explicitly
> | included in activity.info.
>
> I favor including a version string with every bundle.  I favor displaying
> this string in places where it is needed to disambiguate multiple versions
> of an Activity.  I'm merely suggesting that the system not attempt to
> parse it.
>
> You mention ordering.  The Journal designs have long called for all
> columns to be sorted, with the user selecting the order of sorting
> precedence.  One intermediate position would be for the Version column to
> be sorted according to a best-effort ordering that attempts to do
> something sane when faced with any of the common version string
> conventions.
>

I guess the point here is that performing intelligent string comparisons on
several of these schemes requires parsing the string. ;)

- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jameson "Chema" Quinn wrote:
| It is desirable for Sugar to be able to compare versions and
| guess which one is newer.

"Newer" means "more recent".  If this capability is important to you, then
we may simply include a datestamp in each bundle, separate from the
version.  However, I do not know of any planned Sugar feature that would
require the ability to determine which bundle was created most recently.

| If, as is the current plan, multiple versions of
| an activity can coexist on an XO, it is reasonable to want sugar to present
| these in some sane order, and possibly give hints and/or aid if the user
| wants to update and/or garbage collect. Otherwise, we might as well just be
| using activity hash, which can be calculated without being explicitly
| included in activity.info.

I favor including a version string with every bundle.  I favor displaying
this string in places where it is needed to disambiguate multiple versions
of an Activity.  I'm merely suggesting that the system not attempt to
parse it.

You mention ordering.  The Journal designs have long called for all
columns to be sorted, with the user selecting the order of sorting
precedence.  One intermediate position would be for the Version column to
be sorted according to a best-effort ordering that attempts to do
something sane when faced with any of the common version string conventions.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh75ZgACgkQUJT6e6HFtqQePgCglNaySAW67tZIHgbYjIPDmqMt
gKQAn2hV9jHTrZqPfGu7dHkx7KVlvi25
=1hsE
-END PGP SIGNATURE-
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

> I'd like to pose an alternative goal, inspired by your comment: Glucose
> should never attempt to parse version strings.  I believe that we can
> accomplish this without sacrificing any of the user-facing behaviors that
> we truly desire.  The choice of an appropriate versioning scheme may then
> be left to the author.
>

I disagree. It is desirable for Sugar to be able to compare versions and
guess which one is newer. If, as is the current plan, multiple versions of
an activity can coexist on an XO, it is reasonable to want sugar to present
these in some sane order, and possibly give hints and/or aid if the user
wants to update and/or garbage collect. Otherwise, we might as well just be
using activity hash, which can be calculated without being explicitly
included in activity.info.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

On Mon, Jul 14, 2008 at 4:18 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> If we're going to a 'dotted decimal' scheme, we
> should use '.'.
>
> ...
>
>  Is 1.1 "newer" or "older" than 1.11?)


 This is exactly the reason I think that 1-1 ... 1-11 is clearer (you're
right, colon is unworkable because it cannot go in NTFS file names). From an
educational standpoint, 1.10 is teaching kids the wrong ideas about the
decimal system.

I do not think that hyphens are impractical. In most cases people will get
it right the first time by following examples. Those who don't will quickly
learn from installation warnings.

I think anything from 1-3 levels should be allowed, and that 3 == 3-0 ==
3-0-0. Leading zeroes should cause warnings - that will mostly keep things
from looking like dates (even in 2010, bugfix 10 should be rare).
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Benjamin M. Schwartz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Langhoff wrote:
| After
| all, if an activity writer wants to use Klingon characters for
| versioning, hey, let them go wild!

This is actually the key point.  Currently, the versioning system is
embedded into the Glucose code itself, and our plans for handling multiple
versions would require even more code to handle more complex versioning
situations.

I'd like to pose an alternative goal, inspired by your comment: Glucose
should never attempt to parse version strings.  I believe that we can
accomplish this without sacrificing any of the user-facing behaviors that
we truly desire.  The choice of an appropriate versioning scheme may then
be left to the author.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh73RoACgkQUJT6e6HFtqR2TwCfZeK//hNeyD6XxFGD1NkrtcYL
BMYAn0WolFwatGoVgtqwryGHV03WbaH6
=RNKc
-END PGP SIGNATURE-
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[C. Scott Ananian]

On Mon, Jul 14, 2008 at 6:56 PM, Martin Langhoff
<[EMAIL PROTECTED]> wrote:
> Version numbers are used to communicate API/ABI compat and degree/type
> of changes to users. Later in this thread Eben suggests what everyone
> else in the industry is using: major.minor - sounds good to me. Even
> better - and more prevalent in OSS - is major.minor.bugfix .

If we were to make the change, I'd suggest supporting dotted integer
sequences of arbitrary length.  1, 1.2, 1.2.3, and 1.2.3.4 are all
reasonable version numbers.  These are *not* floating point numbers;
they sort based on integer comparison major component first, so 1.1 <
1.11.  Once we've gone that far, we might as well go all the way and
adopt the version number scheme fedora uses, with an epoch and
everything.  But this doesn't actually do anything to solve the
problem Eben first posed, which is why I'm objecting: it seems
needless complexity at the moment, to a format which was explicitly
designed to Keep Things Simple.

> In any case, this issue does not seem to deserve such a colourful
> thread. Maybe we can save our time and effort for other stuff? After

You think this is colorful?  Geesh.  I need to work harder on the other threads.

> all, if an activity writer wants to use Klingon characters for
> versioning, hey, let them go wild!

I am compelled to strongly object.  The updater needs to be able to
compare version numbers.  I refuse to implement Klingon numeral
comparison.

All this stuff is trivial until you are the one who has to implement
the updater.
 --scott

-- 
 ( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Martin Langhoff]

On Tue, Jul 15, 2008 at 6:17 AM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> There was an extensive discussion on this topic a while back on IRC,

Version numbers are used to communicate API/ABI compat and degree/type
of changes to users. Later in this thread Eben suggests what everyone
else in the industry is using: major.minor - sounds good to me. Even
better - and more prevalent in OSS - is major.minor.bugfix .

In any case, this issue does not seem to deserve such a colourful
thread. Maybe we can save our time and effort for other stuff? After
all, if an activity writer wants to use Klingon characters for
versioning, hey, let them go wild!

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
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[C. Scott Ananian]

On Mon, Jul 14, 2008 at 6:48 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> I read on our wiki that the version number was supposed to be monotonically
> increasing.  If that were the case, doing as you suggest isn't valid, as I

Who wrote this?  Did they mean it to be taken this literally, or just
as a guideline?

> would never be able to release anything with a version below 500 once I had,
> defeating the purpose.  Also, the current page on activity bundles
> explicitly states that "Larger versions are considered 'newer'", which is
> simply not the case, even if we do allow your scheme proposed above, which,
> I agree, is technically equivalent.

I proposed two schemes.  The one which said, "just release 10 and 11
at the same time, 10 for 8.1 and 11 for 8.2" conforms with the literal
reading of that wiki page, even if I dispute its authority.
 --scott

-- 
 ( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 6:41 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> On Mon, Jul 14, 2008 at 6:24 PM, Eben Eliason <[EMAIL PROTECTED]>
> wrote:
> > I think this is still a whole bunch clearer than trying to convince
> someone
> > that version 5 is newer than version 10! (where 10 is a "bugfix" release
> to
> > what used to be version 4.)
>
> You're undercutting your own points: what does "newer" mean?  If you
> want chronological "newness", then use ISO8601 dates.  Otherwise, just
> release a version 11 at the same time as 10, so that versions 10 and
> 11 are the chronologically newest releases, 11 for 8.2 users and 10
> for 8.1 users, and those people using '9' don't get confused.  This


This isn't always possible.  If I release version 10 (because it takes
advantage of some new feature in a new OS) and then later find out I have a
critical bug in an older version of the OS that still has a wide support
window, I'm forced to release 11 after 10, even though its an older code
base.  I'm not concerned at all with temporal newness, or this would be a
non-issue.


>
> really seems like a non-issue to me.  If your development style really
> wants to use minor versions, make up your own mapping to integers: 5.0
> = 500, 5.1=501, etc.  But regardless, adding dotted integers for
> version numbers isn't a real concern for me: it touches a number of
> pieces of code and documentation at this point, but we can go ahead
> and make that change early in 9.1 if you like.  But it still doesn't
> actually do anything towards solving the problem you initially posed:
> the only difference between 500 and 5.0 is perceptual.


I read on our wiki that the version number was supposed to be monotonically
increasing.  If that were the case, doing as you suggest isn't valid, as I
would never be able to release anything with a version below 500 once I had,
defeating the purpose.  Also, the current page on activity bundles
explicitly states that "Larger versions are considered 'newer'", which is
simply not the case, even if we do allow your scheme proposed above, which,
I agree, is technically equivalent.

- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[C. Scott Ananian]

On Mon, Jul 14, 2008 at 6:24 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> I think this is still a whole bunch clearer than trying to convince someone
> that version 5 is newer than version 10! (where 10 is a "bugfix" release to
> what used to be version 4.)

You're undercutting your own points: what does "newer" mean?  If you
want chronological "newness", then use ISO8601 dates.  Otherwise, just
release a version 11 at the same time as 10, so that versions 10 and
11 are the chronologically newest releases, 11 for 8.2 users and 10
for 8.1 users, and those people using '9' don't get confused.  This
really seems like a non-issue to me.  If your development style really
wants to use minor versions, make up your own mapping to integers: 5.0
= 500, 5.1=501, etc.  But regardless, adding dotted integers for
version numbers isn't a real concern for me: it touches a number of
pieces of code and documentation at this point, but we can go ahead
and make that change early in 9.1 if you like.  But it still doesn't
actually do anything towards solving the problem you initially posed:
the only difference between 500 and 5.0 is perceptual.
 --scott

-- 
 ( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 6:18 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> On Mon, Jul 14, 2008 at 6:07 PM, Eben Eliason <[EMAIL PROTECTED]>
> wrote:
> > On Mon, Jul 14, 2008 at 5:55 PM, Jameson Chema Quinn <
> [EMAIL PROTECTED]>
>
> I agree with almost everything jquinn said, except for the use of ':'
> to delimit version numbers.  Like it or not, the rest of the software
> world uses '.'.  If we're going to a 'dotted decimal' scheme, we
> should use '.'.  The cost of doing things "our own way" is just too
> high otherwise.
>
> > I don't expect to have any encoded info which makes this decidedly easy.
>  I
> > just want a simple way to say that versions 3.x - 5.x work on  OS release
> > 8.2.  Nothing in the bundle needs to indicate that specifically, but at
> > least we'd have a way to easily document compatibilities. I understand
> what
>
> No, you've missed my point: it is *not possible* to put this
> information in the bundle, because we don't *know* that version 8 is
> incompatible with release 9.1 *until after 9.1 is released*.  So the
> compatibility information has to be maintained externally.
>

On the contrary, you are missing mine.  I don't *want* this in the bundle.
 I want this to be a sentence that can be stated, at some point following
the release of 9.1, by a wiki page, the release notes, a tech support
person, a friend, or the developer herself.  Nothing more.  No technical
magic here.  The technical changes suggested (dotted decimal versioning
scheme) are simply a nicety to make uttering this sentence more natural.


> So, that separates our concerns into two independent problems:
>  a) is it worthwhile to add dotted decimal version numbers?  (I remain
> unconvinced that this solves any problems, and introduces ambiguities
> of comparison:  Is 1.1 "newer" or "older" than 1.11?)


I think this is still a whole bunch clearer than trying to convince someone
that version 5 is newer than version 10! (where 10 is a "bugfix" release to
what used to be version 4.)

- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[C. Scott Ananian]

On Mon, Jul 14, 2008 at 6:07 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 14, 2008 at 5:55 PM, Jameson Chema Quinn <[EMAIL PROTECTED]>

I agree with almost everything jquinn said, except for the use of ':'
to delimit version numbers.  Like it or not, the rest of the software
world uses '.'.  If we're going to a 'dotted decimal' scheme, we
should use '.'.  The cost of doing things "our own way" is just too
high otherwise.

> I don't expect to have any encoded info which makes this decidedly easy.  I
> just want a simple way to say that versions 3.x - 5.x work on  OS release
> 8.2.  Nothing in the bundle needs to indicate that specifically, but at
> least we'd have a way to easily document compatibilities. I understand what

No, you've missed my point: it is *not possible* to put this
information in the bundle, because we don't *know* that version 8 is
incompatible with release 9.1 *until after 9.1 is released*.  So the
compatibility information has to be maintained externally.

So, that separates our concerns into two independent problems:
 a) is it worthwhile to add dotted decimal version numbers?  (I remain
unconvinced that this solves any problems, and introduces ambiguities
of comparison:  Is 1.1 "newer" or "older" than 1.11?)
 b) how to *externally indicate* which versions work with a given release.

  --scott

-- 
 ( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 5:55 PM, Jameson Chema Quinn <[EMAIL PROTECTED]>
wrote:

>
> I agree with the signature approach.  However, I don't really know what
>> happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and
>> 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to
>> coincide with the "level of newness".  This is something we will lose
>> completely without a minor release number.  The logical assumption is that
>> "the bigger the number, the better/newer it is", which is blatantly false
>> when point releases are intermixed with brand new versions with
>> ever-increasing version numbers.  I might decide I need to clear up space,
>> and so delete versions 37 and 38, thinking I was keeping the latest and
>> greatest version 39 and be quite disappointed.
>>
>> - Eben
>>
>
> This idea works well when developers time their new-features releases to
> coincide with Sucrose updates. It starts to break down when that does not
> hold - does version 3.x mean "runs on same Sucrose as 3.0" or "holds
> essentially the same feature-set as 3.0" or some combination of both? I
> think that Eben is assuming the former - that nobody would go back and
> release lower version numbers except in order to maintain system
> compatibility - but this conflicts with a common assumption that major
> version changes are synonymous with major new features.
>
> Basically, there are two separate problems here, and we should not be
> solving them together. One is that the latest release may not be the
> greatest - because of bugfix releases. I agree with Eben's proposal of minor
> version numbers as a (totally optional) solution; as long as the minor/major
> separator is not a decimal separator (that is, [.,]), the meaning is pretty
> self-evident. (I think that : is the best candidate, by analogy with times
> and bible verses.)
>

This is actually my primary concern.


> But the second problem is harder: how do you tell people which versions run
> on which Glucose. Any attempt to encode this implicitly in version numbers
> is, I think, bound to fail, and not too helpful anyway. The update_url
> solution for #4951 fixes the most useful version of this problem - "what is
> the latest working version on my system". I think we can live without a more
> general solution to "will version X run on system Y" - even though that
> means some ugly trial-and-error when sharing activities across Glucose
> versions.
>

I don't expect to have any encoded info which makes this decidedly easy.  I
just want a simple way to say that versions 3.x - 5.x work on  OS release
8.2.  Nothing in the bundle needs to indicate that specifically, but at
least we'd have a way to easily document compatibilities. I understand what
you mean in that activity cycles won't necessarily match OS cycles, and it's
true.  It's possible for several releases to be "designed for" a single OS
version, and likewise possible that a major activity version would span
several OS versions.  I'm mostly trying to safegaurd against the possibility
of future API or other incompatibilities which come from Sugar itself.  It
would be up to the activity developer to decide if they wanted to jump to a
new major version to support a new API or feature which isn't around in
older versions of the OS.

- Eben


>
> ...
>
> and cscott just wrote an email which says many of the same things.
>
> Jameson
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 5:34 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> On Mon, Jul 14, 2008 at 4:49 PM, Eben Eliason <[EMAIL PROTECTED]>
> wrote:
> > I'm not sure this satisfies me.  It might accurately handle the use case
> of
> > updating when upgrading, assuming that activity developers are very
> careful
> > to add extra info about compatibility into the .info file.  It doesn't
> > however, make it easy to decide what version of an activity to download
> if
> > I've never used it before, and I'm not on the most recent release of
> Sugar.
>
> No, this problem is already solved by the scheme I outline.


Can you explain how?  For instance, if I'm looking at a wiki page for an
activity, how does that page tell me which version I need?  How can a
tech-support guru tell the person on the other end of the line what they
need?  It seems your approach only works when software is working it's magic
on the extra info in the .info file.

>
>
> > I agree with the signature approach.  However, I don't really know what
> > happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37,
> and
> > 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38,
> to
> > coincide with the "level of newness".  This is something we will lose
> > completely without a minor release number.  The logical assumption is
> that
> > "the bigger the number, the better/newer it is", which is blatantly false
> > when point releases are intermixed with brand new versions with
> > ever-increasing version numbers.  I might decide I need to clear up
> space,
> > and so delete versions 37 and 38, thinking I was keeping the latest and
> > greatest version 39 and be quite disappointed.
>
> I don't see how your solution solves this problem either.  Say the
> activity author has released 0.4, 0.6, 1, 1.2, and 1.3.  Versions 0.6,
> 1.2, and 1.3 only work on 8.1 (because of a bug in 1.3), but version
> 0.4 and 1.2 work on 8.2 (because 0.4 didn't use the "new" feature that
> was broken in the 8.2 update, and 1.2 didn't have the bug introduced
> in 1.3).  What's the "level of newness"?
>

I still think it mostly solves it.  You're confusing "newer version of an
activity" with "runs on newer version of OS", I think.  For instance, even
though 0.4 runs on 8.2 because it didn't use some new feature of 8.1 doesn't
make it any newer.  It's still old, less mature code, and the UI and feature
set would certainly back that up.  The bugfixes in 1.2 might also make the
activity work on both 8.1 and 8.2, but that doesn't change the fact that the
fixes were still to a version of the activity less mature than 1.3, and
likewise containing fewer features.

Most importantly, you've demonstrated that the "natural ordering" of the
versions is 0.4, 0.6, 1.2, 1.3, which is true regardless of the fact that
1.2 might have been released months after 1.3.  The level of newness seems
intact to me.

Sadly, I think that it's up to the activity authors to ensure that
> newer versions work on older releases.  I admire your desire to make
> more powerful version numbers, but simply adding an extra digit isn't
> going to materially change anything.
>

I think you're wrong.  I think that exposing single digit version numbers
is, subconsciously or not, going to indicate to them that the largest number
is the newest version of the activity.  The problem is that the definition
of newest isn't in sync with expectation.  It's only newest in that it was
released most recently, but that's not what really matters.  What matters is
which of them is the most mature in terms of code/features.

I think the most interesting question is "what's the newest version
> compatible with my release", and that's the problem I've solved.  I


Again, I disagree.   Take, for instance, your example from above. It was
clear that both versions 1.2 and 1.3 work on 8.2.  If 1.2 was released after
(temporally) 1.3, it's technically "newer" and would have a higher version
number (in the old scheme).  It's also compatible with 8.2.  So the newest
version compatible with my release is therefore 1.2, even though there's
actually a newer-as-in-features 1.3 release that I'm really after.

agree that it would be interesting in the future to be able to mark
> activities in the activity list that "can't possibly be expected to
> run" for some reason or another (like an API incompatibility), but I
> don't think I agree that manually putting information in an
> activity.info file is the best way to do that -- for starters, the
> information you'd like to add all have to find its way into that file
> *retroactively* after the new release has come out which is
> incompatible.  A better method would be to provide a standardized way


What?  All I'm suggesting is a minor version number.  Nothing needs to be
added retroactively to existing activities.  We can just assume that absence
of a minor version means that it's X.0 instead.

>
> for a python app to run code which performs tests and returns

Re: [sugar] Activity versioning schema

[Jameson "Chema" Quinn]

> I agree with the signature approach.  However, I don't really know what
> happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and
> 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to
> coincide with the "level of newness".  This is something we will lose
> completely without a minor release number.  The logical assumption is that
> "the bigger the number, the better/newer it is", which is blatantly false
> when point releases are intermixed with brand new versions with
> ever-increasing version numbers.  I might decide I need to clear up space,
> and so delete versions 37 and 38, thinking I was keeping the latest and
> greatest version 39 and be quite disappointed.
>
> - Eben
>

This idea works well when developers time their new-features releases to
coincide with Sucrose updates. It starts to break down when that does not
hold - does version 3.x mean "runs on same Sucrose as 3.0" or "holds
essentially the same feature-set as 3.0" or some combination of both? I
think that Eben is assuming the former - that nobody would go back and
release lower version numbers except in order to maintain system
compatibility - but this conflicts with a common assumption that major
version changes are synonymous with major new features.

Basically, there are two separate problems here, and we should not be
solving them together. One is that the latest release may not be the
greatest - because of bugfix releases. I agree with Eben's proposal of minor
version numbers as a (totally optional) solution; as long as the minor/major
separator is not a decimal separator (that is, [.,]), the meaning is pretty
self-evident. (I think that : is the best candidate, by analogy with times
and bible verses.)

But the second problem is harder: how do you tell people which versions run
on which Glucose. Any attempt to encode this implicitly in version numbers
is, I think, bound to fail, and not too helpful anyway. The update_url
solution for #4951 fixes the most useful version of this problem - "what is
the latest working version on my system". I think we can live without a more
general solution to "will version X run on system Y" - even though that
means some ugly trial-and-error when sharing activities across Glucose
versions.

...

and cscott just wrote an email which says many of the same things.

Jameson
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[C. Scott Ananian]

On Mon, Jul 14, 2008 at 4:49 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> I'm not sure this satisfies me.  It might accurately handle the use case of
> updating when upgrading, assuming that activity developers are very careful
> to add extra info about compatibility into the .info file.  It doesn't
> however, make it easy to decide what version of an activity to download if
> I've never used it before, and I'm not on the most recent release of Sugar.

No, this problem is already solved by the scheme I outline.

> I agree with the signature approach.  However, I don't really know what
> happens when I have 37, 38, and 39 where 39 is a "bugfix" release of 37, and
> 39 is a "brand new version"...I'd prefer to see them ordered 37, 39, 38, to
> coincide with the "level of newness".  This is something we will lose
> completely without a minor release number.  The logical assumption is that
> "the bigger the number, the better/newer it is", which is blatantly false
> when point releases are intermixed with brand new versions with
> ever-increasing version numbers.  I might decide I need to clear up space,
> and so delete versions 37 and 38, thinking I was keeping the latest and
> greatest version 39 and be quite disappointed.

I don't see how your solution solves this problem either.  Say the
activity author has released 0.4, 0.6, 1, 1.2, and 1.3.  Versions 0.6,
1.2, and 1.3 only work on 8.1 (because of a bug in 1.3), but version
0.4 and 1.2 work on 8.2 (because 0.4 didn't use the "new" feature that
was broken in the 8.2 update, and 1.2 didn't have the bug introduced
in 1.3).  What's the "level of newness"?

Sadly, I think that it's up to the activity authors to ensure that
newer versions work on older releases.  I admire your desire to make
more powerful version numbers, but simply adding an extra digit isn't
going to materially change anything.

I think the most interesting question is "what's the newest version
compatible with my release", and that's the problem I've solved.  I
agree that it would be interesting in the future to be able to mark
activities in the activity list that "can't possibly be expected to
run" for some reason or another (like an API incompatibility), but I
don't think I agree that manually putting information in an
activity.info file is the best way to do that -- for starters, the
information you'd like to add all have to find its way into that file
*retroactively* after the new release has come out which is
incompatible.  A better method would be to provide a standardized way
for a python app to run code which performs tests and returns a
go/no-go, or else to just mark activities which fail during launch.
  --scott

-- 
 ( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Eben Eliason]

Comments follow...

On Mon, Jul 14, 2008 at 4:09 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> On Mon, Jul 14, 2008 at 3:22 PM, Eben Eliason <[EMAIL PROTECTED]>
> wrote:
> > They don't get it? Or they don't get how a single integer is supposed to
> be
> > sufficient, and therefor use their own methods?  Do you have examples of
> > specific "random and bogus" strings we can look at to see what's been
> tried?
>
> On an XO:
> $ python2.5
> >>> act_page = 'http://wiki.laptop.org/go/Activities'
> >>> import urlparse, re, urllib
> >>> import bitfrost.update.actutils as actutils
> >>> urls = [urlparse.urljoin(act_page, url) for url in
> re.findall(r'href="([^"]*)"', urllib.urlopen(act_page).read()) if
> url.endswith('.xo')]
> >>> for u in urls:
> ...   try:
> ... cp = actutils.activity_info_from_url(u)
> ...   except:
> ... print "BAD activity.info", u
> ... continue
> ...   if not cp.has_option('Activity','activity_version'):
> ... print "MISSING VERSION", u
> ... continue
> ...   try:
> ... pass
> ...   except: pass
> ...   v = cp.get('Activity','activity_version')
> ...   try:
> ... assert not v.startswith('0')
> ... assert not '.' in v
> ... v = int(v)
> ...   except:
> ... print "BAD VERSION", u, v
> ...
> MISSING VERSION http://wiki.laptop.org/images/1/1d/ViewSlides-3.xo
> BAD activity.info http://wiki.laptop.org/images/7/7e/Gmail-2.xo
> BAD activity.info http://opteron.9grid.us/olpc/inferno-012808.xo
> MISSING VERSION http://wiki.laptop.org/images/b/b2/ProducePuzzle.xo
> BAD activity.info http://www.linuxuser.at/dl.php?i=ImageQuiz.xo
>
> This is under-reported, since many of the bad activities just set
> activity_version=1:
>
> >>> def bad_ver(v):
> ...   try:
> ... assert not v.startswith('0')
> ... int(v)
> ... return False # good
> ...   except:
> ... return True
> ...
> >>> vers = [v for v in re.findall(r' class="olpc-activity-version">([^<]*)',
> urllib.urlopen(act_page).read()) if bad_ver(v)]
> >>> vers
> ['\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '1-beta', '1.4', '1.7', '\xe2\x80\x93', '0.29', '3.3', '\xe2\x80\x93',
> '012808', '\xe2\x80\x93', '\xe2\x80\x93', '0.4', '', '0.33 - beta 3',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
> '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '0.2',
> '080601', '080601', '080601', '080601', '080601', '080601', '080601',
> '080601', '080601', '080601', '', '\xe2\x80\x93', '[beta-1]',
> '\xe2\x80\x93', '0.1', '\xe2\x80\x93', '0.1']
> >>>
>
> >>  b) There is an alternative mechanism already in place for handling
> >> dependencies on specific versions, documented in the [[Activity
> >> bundles]] entry for 'update_url'.  Basically, you can specify a
> >> different version number as appropriate based on the current OS build,
> >> release version, and release major version.  So you can say, "version
> >> 8 if you are using 8.1, or version 9 if you are using 8.2".
> >
> > How does this actually help the user, or the tech support team when
> someone
> > wants to know "what version of chat works with 9.1.0?"  Short of saying
> > "Well, the system will (should) know if it can support an activity, so
> > download it and see..." what do we have?  We say "Well, versions 36-38,
> and
> > also 40, and also 42, work with 9.1, but not 39 and 41...those are
> bugfixes
> > for 8.2".  This seems silly to me.  Just say versions 4.x and 5.x work
> with
> > 8.2 and 6.x works with 9.1.  This also makes displaying multiple versions
> > (activity "threads") possible in the OS.  Otherwise how can we reasonable
> > sort/group the activities in any way that makes sense?
> > - Eben
>
> Just say, "does the activity updater show an update for your version
> of Chat? if so, install it, please."
>

I'm not sure this satisfies me.  It might accurately handle the use case of
updating when upgrading, assuming that activity developers are very careful
to add extra info about compatibility into the .info file.  It doesn't
however, make it easy to decide what version of an activity to download if
I've never used it before, and I'm not on the most recent release of Sugar.
 What if I still have 8.1 even though 8.2 is out, and I find a cool new
science activity I want.  What version to get?  Well, maybe 23.  Maybe 32.
 Maybe 24-31 are all incompatible because of a new API in 8.2, but how would
I know?  Is the best suggestion to download a really old version and then
wait for it to inform me of an update?


>
> The alternative is not going to work, because the activity authors
> can't keep their bundle ids straight, much less collectively agree to
> use release-synchronized version numbers in a sane way. You are
> proposing a more complicated system, which just introduces more ways
> to go wrong w/o actually addressing any part of the real metadata
> probl

Re: [sugar] Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 3:49 PM, Michael Stone <[EMAIL PROTECTED]> wrote:

> > Otherwise how can we reasonable sort/group the activities in any way
> > that makes sense?
>
> I suggested one (stupidly slow, but very general) approach based on the
> Travelling Salesman problem. To recap:
>
> Regard all activities as nodes in a fully connected graph. Let
> activities state that they are close to some collection of other
> activities according to any system you please. (e.g. specify a metric on
> activities, plug in some heuristics on names and numbers, give a list of
> 'similar' activities, do cosine similarity on keyword vectors, etc.)
>
> When you learn that A thinks it should be close to B, shorten the edge
> between A and B.
>
> "Solve" the TSP for the graph. Approximate solutions are fine.
>

An interesting idea, for sure, but not ultimately what concerns me.  We
actually know the "grouping"...it will be determined by the signature of the
bundle, with broken signatures splitting the grouping.  I was more concerned
with sorting the available versions in a "meaningful" way.  Perhaps this is
too lofty a goal.

- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[C. Scott Ananian]

On Mon, Jul 14, 2008 at 3:22 PM, Eben Eliason <[EMAIL PROTECTED]> wrote:
> They don't get it? Or they don't get how a single integer is supposed to be
> sufficient, and therefor use their own methods?  Do you have examples of
> specific "random and bogus" strings we can look at to see what's been tried?

On an XO:
$ python2.5
>>> act_page = 'http://wiki.laptop.org/go/Activities'
>>> import urlparse, re, urllib
>>> import bitfrost.update.actutils as actutils
>>> urls = [urlparse.urljoin(act_page, url) for url in 
>>> re.findall(r'href="([^"]*)"', urllib.urlopen(act_page).read()) if 
>>> url.endswith('.xo')]
>>> for u in urls:
...   try:
... cp = actutils.activity_info_from_url(u)
...   except:
... print "BAD activity.info", u
... continue
...   if not cp.has_option('Activity','activity_version'):
... print "MISSING VERSION", u
... continue
...   try:
... pass
...   except: pass
...   v = cp.get('Activity','activity_version')
...   try:
... assert not v.startswith('0')
... assert not '.' in v
... v = int(v)
...   except:
... print "BAD VERSION", u, v
...
MISSING VERSION http://wiki.laptop.org/images/1/1d/ViewSlides-3.xo
BAD activity.info http://wiki.laptop.org/images/7/7e/Gmail-2.xo
BAD activity.info http://opteron.9grid.us/olpc/inferno-012808.xo
MISSING VERSION http://wiki.laptop.org/images/b/b2/ProducePuzzle.xo
BAD activity.info http://www.linuxuser.at/dl.php?i=ImageQuiz.xo

This is under-reported, since many of the bad activities just set
activity_version=1:

>>> def bad_ver(v):
...   try:
... assert not v.startswith('0')
... int(v)
... return False # good
...   except:
... return True
...
>>> vers = [v for v in re.findall(r'>> class="olpc-activity-version">([^<]*)', 
>>> urllib.urlopen(act_page).read()) if bad_ver(v)]
>>> vers
['\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
'1-beta', '1.4', '1.7', '\xe2\x80\x93', '0.29', '3.3', '\xe2\x80\x93',
'012808', '\xe2\x80\x93', '\xe2\x80\x93', '0.4', '', '0.33 - beta 3',
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93',
'\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '\xe2\x80\x93', '0.2',
'080601', '080601', '080601', '080601', '080601', '080601', '080601',
'080601', '080601', '080601', '', '\xe2\x80\x93', '[beta-1]',
'\xe2\x80\x93', '0.1', '\xe2\x80\x93', '0.1']
>>>

>>  b) There is an alternative mechanism already in place for handling
>> dependencies on specific versions, documented in the [[Activity
>> bundles]] entry for 'update_url'.  Basically, you can specify a
>> different version number as appropriate based on the current OS build,
>> release version, and release major version.  So you can say, "version
>> 8 if you are using 8.1, or version 9 if you are using 8.2".
>
> How does this actually help the user, or the tech support team when someone
> wants to know "what version of chat works with 9.1.0?"  Short of saying
> "Well, the system will (should) know if it can support an activity, so
> download it and see..." what do we have?  We say "Well, versions 36-38, and
> also 40, and also 42, work with 9.1, but not 39 and 41...those are bugfixes
> for 8.2".  This seems silly to me.  Just say versions 4.x and 5.x work with
> 8.2 and 6.x works with 9.1.  This also makes displaying multiple versions
> (activity "threads") possible in the OS.  Otherwise how can we reasonable
> sort/group the activities in any way that makes sense?
> - Eben

Just say, "does the activity updater show an update for your version
of Chat? if so, install it, please."

The alternative is not going to work, because the activity authors
can't keep their bundle ids straight, much less collectively agree to
use release-synchronized version numbers in a sane way. You are
proposing a more complicated system, which just introduces more ways
to go wrong w/o actually addressing any part of the real metadata
problem.

As regard to sorting/grouping: we already discussed that at our last
mini-conference:  simple ordering by version number, with group breaks
when signature changes.  There is an additional grouping mechanism in
the updater, as well, that lets countries define things like "G1G1
activities" or "Peru activities".
 --scott

-- 
 ( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Michael Stone]

> Otherwise how can we reasonable sort/group the activities in any way
> that makes sense?

I suggested one (stupidly slow, but very general) approach based on the
Travelling Salesman problem. To recap:

Regard all activities as nodes in a fully connected graph. Let
activities state that they are close to some collection of other
activities according to any system you please. (e.g. specify a metric on
activities, plug in some heuristics on names and numbers, give a list of
'similar' activities, do cosine similarity on keyword vectors, etc.)

When you learn that A thinks it should be close to B, shorten the edge
between A and B. 

"Solve" the TSP for the graph. Approximate solutions are fine.

Designate a starting point (I suggest a 'Help' activity) and order your
activities according to your solution. You can even do fancy grouping
tricks for small-diameter subgraphs.

Michael
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[Eben Eliason]

On Mon, Jul 14, 2008 at 3:09 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> 2008/7/14 Eben Eliason <[EMAIL PROTECTED]>:
> > There was an extensive discussion on this topic a while back on IRC,
> which I
> > unfortunately don't have a record of.  There was also mention of this in
> the
> > mailing lists not too long ago, initiated by
> > Morgan: http://lists.laptop.org/pipermail/sugar/2008-May/005895.html.
> >  Finally, I brought this up at the end of a recent tech team meeting (1
> or 2
> > weeks ago?) as a topic that needed our attention in order to make the
> > update/upgrade system work (specifically, regarding the need for minor
> > versions so that we can make bugfixes to older versions of an activity
> (say,
> > 4.x) while keeping 5.x for all versions that work with the next version
> of
> > the OS).  I think deciding how we version activities is a critical part
> of
> > making our OS releases work, and can assist in the problem of answering
> > "Which activities work with my release?".  Answering 4.x is nicer than
> [34 -
> > 42], and MUCH nicer than [36-38, 40, 42].
> > The "agreement" I speak of was really a lack of any voiced disagreement
> when
> > I mentioned this issue at the meeting.
>
> From extensive auditing of current activity version numbers:
>  a) a large number of activities are using completely random and bogus
> strings for their version numbers.  "Just an integer" is about the
> simplest possible scheme, and people still don't get it.  I'm
> unconvinced that any more complicated scheme will work better.


They don't get it? Or they don't get how a single integer is supposed to be
sufficient, and therefor use their own methods?  Do you have examples of
specific "random and bogus" strings we can look at to see what's been tried?

>
>  b) There is an alternative mechanism already in place for handling
> dependencies on specific versions, documented in the [[Activity
> bundles]] entry for 'update_url'.  Basically, you can specify a
> different version number as appropriate based on the current OS build,
> release version, and release major version.  So you can say, "version
> 8 if you are using 8.1, or version 9 if you are using 8.2".


How does this actually help the user, or the tech support team when someone
wants to know "what version of chat works with 9.1.0?"  Short of saying
"Well, the system will (should) know if it can support an activity, so
download it and see..." what do we have?  We say "Well, versions 36-38, and
also 40, and also 42, work with 9.1, but not 39 and 41...those are bugfixes
for 8.2".  This seems silly to me.  Just say versions 4.x and 5.x work with
8.2 and 6.x works with 9.1.  This also makes displaying multiple versions
(activity "threads") possible in the OS.  Otherwise how can we reasonable
sort/group the activities in any way that makes sense?

- Eben
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Activity versioning schema

[C. Scott Ananian]

2008/7/14 Eben Eliason <[EMAIL PROTECTED]>:
> There was an extensive discussion on this topic a while back on IRC, which I
> unfortunately don't have a record of.  There was also mention of this in the
> mailing lists not too long ago, initiated by
> Morgan: http://lists.laptop.org/pipermail/sugar/2008-May/005895.html.
>  Finally, I brought this up at the end of a recent tech team meeting (1 or 2
> weeks ago?) as a topic that needed our attention in order to make the
> update/upgrade system work (specifically, regarding the need for minor
> versions so that we can make bugfixes to older versions of an activity (say,
> 4.x) while keeping 5.x for all versions that work with the next version of
> the OS).  I think deciding how we version activities is a critical part of
> making our OS releases work, and can assist in the problem of answering
> "Which activities work with my release?".  Answering 4.x is nicer than [34 -
> 42], and MUCH nicer than [36-38, 40, 42].
> The "agreement" I speak of was really a lack of any voiced disagreement when
> I mentioned this issue at the meeting.

>From extensive auditing of current activity version numbers:
 a) a large number of activities are using completely random and bogus
strings for their version numbers.  "Just an integer" is about the
simplest possible scheme, and people still don't get it.  I'm
unconvinced that any more complicated scheme will work better.
 b) There is an alternative mechanism already in place for handling
dependencies on specific versions, documented in the [[Activity
bundles]] entry for 'update_url'.  Basically, you can specify a
different version number as appropriate based on the current OS build,
release version, and release major version.  So you can say, "version
8 if you are using 8.1, or version 9 if you are using 8.2".

A dotted integer scheme would let you "make space" between 8 and 9 if
needed, but there is no technical reason why you couldn't update the
activity info later to say, "version 10 if you are using 8.1, or
version 11 if you are using 8.2".  It's not quite as pretty, but the
goal was to keep the activity bundle information as simple as
possible, and there is no *technical* reason we need to complicate it.
 --scott

-- 
 ( http://cscott.net/ )
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] Activity versioning schema

[Eben Eliason]

There was an extensive discussion on this topic a while back on IRC, which I
unfortunately don't have a record of.  There was also mention of this in the
mailing lists not too long ago, initiated by Morgan:
http://lists.laptop.org/pipermail/sugar/2008-May/005895.html.  Finally, I
brought this up at the end of a recent tech team meeting (1 or 2 weeks ago?)
as a topic that needed our attention in order to make the update/upgrade
system work (specifically, regarding the need for minor versions so that we
can make bugfixes to older versions of an activity (say, 4.x) while keeping
5.x for all versions that work with the next version of the OS).  I think
deciding how we version activities is a critical part of making our OS
releases work, and can assist in the problem of answering "Which activities
work with my release?".  Answering 4.x is nicer than [34 - 42], and MUCH
nicer than [36-38, 40, 42].
The "agreement" I speak of was really a lack of any voiced disagreement when
I mentioned this issue at the meeting.

- Eben


On Sat, Jul 12, 2008 at 10:52 PM, Michael Stone <[EMAIL PROTECTED]> wrote:

> > That's true, however I think it's also been agreed that...
>
> Could you please cite the discussion leading up to the agreement you're
> referring to?
>
> Thanks,
>
> Michael
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar