On Mon, May 19, 2008 at 2:12 PM, Jameson Chema Quinn <[EMAIL PROTECTED]> 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@lists.laptop.org http://lists.laptop.org/listinfo/sugar