[sugar] Activity versions

[Eben Eliason]

Yes, I've never understood the reason for the integer versioning
system for activities.  One argument I'm aware of is that it could
make things simpler for kids, who might not understand more complex
schemes.  However, as you point out, if the relation between two
versions of a given activity doesn't actually have any meaning, then
the point is moot, and we're doing a greater disservice by hiding the
real information needed to understand the system in any meaningful
way.  Chances are that any kid who has the chops to hack into an
activity with Develop can probably grasp a more complex versioning
scheme.

If we still wanted to impose some arbitrary restrictions to keep
things sane, we could limit to "major" and "minor" releases, and even
have a checkbox (or something) in Develop which indicates if the
resulting build should be a major or minor release, thus automatically
updating bundle 2.5 to 3.0 or 2.6 respectively.  This could be a nice
middle ground. (To be clear, anytime the "identity" of an activity
changes (eg. it is signed by a new author) the version thread would
start over, so the major/minor release management only needs to be
maintained by the individual or group of individuals collaborating to
create an activity.)

- Eben


On Mon, May 19, 2008 at 10:33 AM, Morgan Collett
<morgan.collett at gmail.com> wrote:
> On Mon, May 19, 2008 at 2:12 PM, Jameson Chema Quinn
> <jquinn at cs.oberlin.edu> wrote:
>>
>> * Cannot have two versions of an activity bundle installed at once (dev and
>> stable) while debugging - esp. necessary for working on Develop itself.
>> Also, you are forced to churn the activity.info version number (upwards or
>> downwards, it doesn't matter) every debug cycle, because "same version"
>> silently fails to install.
>
> This reminds me of my pet issue about activity version numbers: There
> is no way to branch development. This is especially relevant with
> activities decoupled from the builds.
>
> For instance: Chat-35.xo is included in the Update.1 activity repo
> (http://mock.laptop.org/repos/local.update1/XOS/index.html). Chat-38
> will be the next development release, and will probably depend on new
> features in Sugar introduced since Update.1. What if we need a bugfix
> release for Update.1? What version will that be? If it is Chat-39,
> then Chat-38 and Chat-40 (perhaps another development release) would
> not be related to Chat-39 in any way.
>
> I think this is also an issue once Develop is available, since if I
> were to edit an activity in Develop and produce a bundle with the next
> version number as Jameson described, it would conflict with the next
> "real" release done by that activity's author.
>
> Since we struggle to get consensus on issues like a release
> name/number, can we get a discussion on the following bite sized
> pieces of an issue?
>
> * Is the current activity version numbering inadequate, as I am proposing?
> * Is changing it to (or allowing) a dotted numeric scheme (Chat-38.2)
> a good way to go?
> (For example, I might use odd numbers for development series and even
> numbers for stable releases - Chat-37.2 next, Chat-38 for Sucrose 0.82
> / OLPC 8.02) and Chat-35.1 for a bugfix for Update.1)
> * Would that be an intrusive change?
>
> Regards
> Morgan
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>