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

Re: [Sc-devel] 3.2 RC cutoff time [was Re: Quarks and svn]



Yes, sorry for sneaking that one in Josh!

I remembered it because I was looking to check where to set the
version that appears in the SuperCollider>About menu. Josh, remember
to change the version name from "-Unofficial Build-" in
/Resources/Info.plist ...

So is it 5pm PST (Pacific Standard Time, GMT-8) you mean? (about 8
hours from now) I'm not v familiar with US timezones. Happy with your
suggested cutoff.

Dan


2008/1/27, Josh Parmenter <josh@xxxxxxxxxxxxxxxxx>:
> cool.
>
> Can we set a cut-off time for commits to today's RC? I was about to
> start trying to package, and with Dan's commit, it reminded me that I
> should wait until all commits are in.
>
> Let's say 5pm US West Coast time?
>
> Josh
>
> On Jan 27, 2008, at 8:28 AM, Dan Stowell wrote:
>
> > 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
> > _______________________________________________
> > Sc-devel mailing list
> > Sc-devel@xxxxxxxxxxxxxxx
> > http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>
> ******************************************
> /* Joshua D. Parmenter
> http://www.realizedsound.net/josh/
>
> "Every composer – at all times and in all cases – gives his own
> interpretation of how modern society is structured: whether actively
> or passively, consciously or unconsciously, he makes choices in this
> regard. He may be conservative or he may subject himself to continual
> renewal; or he may strive for a revolutionary, historical or social
> palingenesis." - Luigi Nono
> */
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@xxxxxxxxxxxxxxx
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
>


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