>
> 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
>