Re: [sugar] Activity versions
On Mon, May 19, 2008 at 4:33 PM, Morgan Collett [EMAIL PROTECTED] wrote: 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) I'm ok with all this, even if I haven't devoted a good deal of thought to it. * Would that be an intrusive change? Not using dotted version numbers, but supporting several versions of the same bundle would be a bit invasive, although we certainly need to do it at some point. We would need for the PS to support it though. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activity versions
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
Re: [sugar] Activity versions
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 [EMAIL PROTECTED] wrote: 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 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
