[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sc-devel] Re: Quarks and svn
I'm not sure that using an opaque version string is the best way to
go. If adding this functionality, surely we should have a generic
ability to query SC to say "are you version 3.1 or greater?"
Here's a suggestion:
+ Main {
classvar scVersionMajor=3, scVersionMinor=1, scVersionPostfix=".1";
versionString {^[scVersionMajor, ".", scVersionMinor, scVersionPostfix].join}
versionAtLeast { |maj, min|
^((maj>=scVersionMajor) and:{ min.isNil or: { min>=scVersionMinor } })
}
versionAtMost { |maj, min|
^((maj<=scVersionMajor) and:{ min.isNil or: { min<=scVersionMinor } })
}
}
The major and minor parts are numbers to enable comparison but the
postfix is a string to allow for "3.2rc2" and the like - this implies
that the postfix shouldn't be significant enough to have compatibility
implications, which I think is reasonable.
So in a quarky context this should allow us to specify, for example,
that rev 147 is compatible with SC 3.2 "or greater" without having to
update our quarks at all to assert that they're also compatible with
SC 3.2.1 or 3.3. Something vaguely along the lines of
\versions:
(
[nil,"3.0"] -> 134, // for 3.0 and lower (!)
["3.1", "3.1"] -> 147, // for 3.1 only
["3.2",nil] -> 148 // For anything later
)
with the following method added to Quark:
svnRevForSCVersion {
var lowest, highest;
if(versions.isNil){ ^"HEAD" }; // ??
versions.keysValuesDo{|ver, svnRev|
lowest = ver[0];
highest = ver[1];
if((lowest.isNil or: {Main.versionAtLeast(lowest[0], lowest[2])})
and:{ highest.isNil or: {Main.versionAtMost(highest[0],
highest[2])} }){
^svnRev;
}
^nil; // ??
}
}
Whaddyasay?
Dan
2007/12/20, Scott Wilson <i@xxxxxxxxxxxxxx>:
>
>
> On 20 Dec 2007, at 00:44, felix wrote:
> okay to add ?
>
> Main
> version { ^"3.1.1" }
>
>
> On Dec 15, 2007 6:04 PM, felix <felix@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> >
> >
> > can SC programmatically declare its version yet ?
>
>
> quarkfile:
>
> (
> ..
> \versions:
> (
> "3.1.1" -> 145 // svn revision number
> )
> ..
> )
>
> thus you could fix bugs related to the 3.1.1 version
>
> you could then commit changes for the 3.2 version
>
> (
> ..
> \versions:
> (
> "3.1.1" -> 147, // svn revision number
> "3.2" -> 148
> )
> ..
> )
>
>
> but you would have a hard time going back to 147 and fixing a bug there (you
> could only commit up to 149) and then returning to 3.2 world to further
> develop
>
> but this is a rare case to fuss over considering the utility and audience
> size let's be realistic here yeah ?
>
>
> Seems sensible. In most cases compatibility would not break between point
> versions of the app anyway, and bug fixes would thus apply retroactively, so
> if you wanted to do it:
>
> "3.1.1" -> 148, // svn revision number
> "3.2" -> 148
>
> If it's a question of avoiding the additional testing then you're not bug
> fixing for earlier releases anyway (which in fact seems quite reasonable)
> and the versions can just be about compatibility issues.
>
> S.
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://www.create.ucsb.edu/mailman/listinfo/sc-devel
>
>
--
http://www.mcld.co.uk