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
_______________________________________________
Sc-devel mailing list
Sc-devel@xxxxxxxxxxxxxxx
http://www.create.ucsb.edu/mailman/listinfo/sc-devel