On Wed, Dec 02, 2009 at 04:38:56PM +0100, Bert Freudenberg wrote:
> On 30.11.2009, at 21:24, Bert Freudenberg wrote:
> > 
> > On 30.11.2009, at 20:02, Aleksey Lim wrote:
> >> 
> >> On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote:
> >>> On 11/30/2009 10:00 AM, Bert Freudenberg wrote:
> >>>> On 29.11.2009, at 20:50, Simon Schampijer wrote:
> >>>>> 
> >>>>> 
> >>>>> Well, if an activity will work for an older release is not only
> >>>>> determined by the activity version number. For example, activities that
> >>>>> moved to the new toolbar design are not working for older releases<
> >>>>> 0.86. I don't think we can always avoid breaking backwards 
> >>>>> compatibility.
> >>>> 
> >>>> But so far we have managed to make is at least *possible* for an 
> >>>> activity author to have a single activity version run under all Sugar 
> >>>> versions. This would be the first instance where the author would not 
> >>>> have that chance.
> >>>> 
> >>>> I'm pretty sure we can find a scheme that both allows a single activity 
> >>>> bundle to provide dotted version numbers for new Sugar, but keep working 
> >>>> in old Sugar.
> >>>> 
> >>>> E.g., we do not have to re-use the "activity_version" field if that 
> >>>> breaks the parsing in older versions. It could be a new field named 
> >>>> "dotted_activity_version" or simply "version" or something else. An 
> >>>> activity author who cared could then provide both, a decimal and a 
> >>>> dotted activity version.
> >>>> 
> >>>> - Bert -
> >>> 
> >>> Sorry, for the mixup. Yes we could add a way for the dotted version 
> >>> number, and your idea sounds good. How does Bert's idea from above 
> >>> sounds to others?
> >> 
> >> +1, but maybe use "activity_release"(or so) instead of 
> >> "dotted_activity_version",
> >> the full version in 0.88+ will be <activity_version>.<activity_release>?
> > 
> > That would link the old and new version field - I thought of them as being 
> > independent. Basically, the old activity_version field would be a like a 
> > build number, increasing for every build, as we did before. It would be 
> > optional in Sugar 0.88. The "real" user-visible version number would be the 
> > dotted one in a different field.
> > 
> > An activity author who wants to support both could keep incrementing 
> > activity_version, and assign dotted version numbers independently.
> > 
> > - Bert -
> 
> Thinking about this, for Etoys it doesn't really make a difference. We can as 
> well switch to the dotted-only scheme.
> 
> So unless other activity authors feel backwards compatibility is needed, just 
> use whatever is simplest.
> 
> Is this already written up as a feature? Couldn't find it.

I've created
http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions
and wrote several options of your proposal(how I understood it)
in 
http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description

Also I pushed it to "Feature Ready for Release Manager" group though
this feature doesn't meet all requirements(there is no owner, I guess it
will be trivial to code it) but it let us do not forget about this
feature.

-- 
Aleksey
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Reply via email to