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

Re: [Sc-devel] 3.2 packaging



Absolutely agree with Dan on need to get a baseline 3.2 sorted soon (next 24 hours), ahead of any special installer.

Scott, your suggestions sound like they will need a fuller discussion. There have been many other changes since 3.1 we need to get out there officially. 3.2 tag should go in soon. We can then go into the whole installer thing in more detail, but the priority is to have a base 3.2 especially so everyone can check code for the book with a known version.

If there is quick resolution of other issues, we can always include 3.2.2 or whatever on the final DVD, but we'll have to see what gets resolved within the short timescale!

best
Nick


On 27 Jan 2008, at 14:59, Dan Stowell wrote:

Wait a minute, I don't understand what's being discussed here: are
these changes expected to go into 3.2? It sounds like quite a
significant change and we're already about a week late in fixing the
first release candidate.

If these changes affect the build of SC 3.2 at all then we shouldn't
do them, they've missed the boat. If we're just discussing whether or
not to put quarks into the package downloads, or exactly how to put
together the OSX installer package, then fine.

Dan


2008/1/27, Scott Wilson <i@xxxxxxxxxxxxxx>:

On 27 Jan 2008, at 05:39, Click Nilson wrote:

I think we should resolve the status of 3.2 too; at what point will
a simple download be available on sourceforge? When do we tag the
source and when is testing officially over? Afraid I don't know how
to tag the source tree, and how to best motivate you all through a
testing regime ;  ) I just know we need to resolve this soon.

On the extensions issue, I would just have the extra directory for
all third party libraries/quarks/extensions in the SC application
folder (and not installed by default), and let the user then place
them where they like; maybe have some quark or quark like
functionality to put symbolic links in the platform specific
extensions as before.

This seems unnecessarily flexible to me (why do I need to put them
anywhere?) and complicates installation and configuration. IIRC,
quarks need write access to their directory, so linking to them in
the applications folder means yet more potential permissions issues.
I'm in favour of moving synthdefs and recordings into the application
support directories as well for this reason. It would make more sense
to have the installer put everything there, and make symlinks to them
in the application directory.

. OR, we just offer a package with the extensions in the
SuperCollider_f folder and a README.

So this is the option that seems to require the least future
support and causes least messiness on machines. Particularly for
those who have multiple versions of SC around!

I think some of this really arises from the current state of affairs
and will be much simpler once a few issues are resolved. It seems to me:

- Any extension we include in the distribution should be a quark
(this needs the UGen issue to be sorted, yes?)
- There should be a package so installation can be simple and
automated for new and general users.
- Since quarks are versioned the installer can check this and
overwrite as appropriate.
- The multiple versions issue really comes down to the need to
selectively include extensions at compile time, yes? We need a
mechanism for this.
- People who have the multiple versions issue are likely developers,
and know how to deal with extensions, accounts, etc. manually if
needed. It's more important to make life simple for general and new
users than for us (I say at the risk of re-igniting the great quarks
svn debate of 2007 ;-)

S.
_______________________________________________
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