[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sc-devel] Quarks and svn



Belatedly committed this (rev 7132), now SC can declare its version:

 Main.version

I haven't committed the change to Quark to decide on different
revisions since that would take more work.

Dan


2007/12/20, Dan Stowell <danstowell@xxxxxxxxx>:
> 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
>


-- 
http://www.mcld.co.uk