[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... PST! I figure most of you Europeans will be heading to bed by then, and that gives me a couple hours to build stuff.

Josh

On Jan 27, 2008, at 9:07 AM, Dan Stowell wrote:

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
_______________________________________________
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
*/