On Mon, May 19, 2008 at 2:12 PM, Jameson Chema Quinn
> * 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?

Sugar mailing list

Reply via email to