[Sugar-devel] Activity Versioning - Dotted Scheme
Gary C Martin
gary at garycmartin.com
Tue Nov 24 07:42:02 EST 2009
On 24 Nov 2009, at 11:20, Simon Schampijer wrote:
> as a follow up on an older thread:
> - we want to get the versioning sorted in 0.88 for real. So far we came
> up with these three options:
> a) The release cycle dependent one: Activities name their activity after
> the Sugar version they are developed against. If it was released during
> the 0.88 cycle and developed against 0.88, then it would be 0.88.x.
Should we also try and resolve the Fructose issue as well here? Is Fructose just a random grab bag of demo activities, or is it the set of activities that are dependant on a single specific release of Glucose? Right now it contains a mix of both. I'd be against including Sugar version numbers in activity version number (unless perhaps they fail to work in other sugar releases). Activity development should be as far removed from the Glucose development cycle as is feasibly possible.
If Fructose becomes the set of Glucose dependent activities (like Browse), they could be the only ones that require special versioning support
> b) MAJOR.MINOR (x.y): The new Browse activity for 0.88 would be 115.0.
> Fixes would go into 115.1, 115.2...
Yes, seems simple enough, but only if/when you have to support an activity that has to fork compatibility between Sugar releases.
> c) MAJOR.MINOR.PATCH (x.y.z) The new Browse activity for 0.88 would be
> 115.0.0. Fixes would go into 115.1.0, 115.2.1...
Not sure this adds much to the above major.minor option.
> What do people like best?
We need to keep in mind not breaking existing deployments. If I have to start releasing Moon-11.0.xo, Moon-11.1.xo, Moon-11.2.xo, I'd be really annoyed/frustrated if this broke things for our current user base – so I guess that means I'll be sticking with integer version numbers for all my activity work in the foreseeable future, which ever way this goes.
More information about the Sugar-devel