Re: [Sc-devel] Re: Quarks and svn

[Scott Wilson <i@xxxxxxxxxxxxxx>]

On 14 Dec 2007, at 19:40, felix wrote:

On Dec 14, 2007 2:05 PM, Scott Wilson <i@xxxxxxxxxxxxxx> wrote:

I think packages that are

installed by Quarks should be tested and stable.

but one of the things about smalltalky-things and especially the sc environment is that the community often agrees to make changes to the default library, and this often impacts quarks.

so an svn quark is assumed to be kept easily up to date with the svn (HEAD) of sc itself.

my assumption is that a quark is HEAD, just as sc is currently HEAD.

for a binary distribution, its supposed to be a freeze frame.  

in some cases (perhaps for crucial when it gets quarked), it would be useful to branch off a 3.3 compat quark of it.  I would definitely do that if and when I change the gui system.

that way the day to day quark can be updated to keep up to date with major changes to the GUI framework etc.  keep it operational, get recent bug fixes in.

 

If you're using what
is essentially a development repository for distribution you will
always have the problem of bleeding edge stuff breaking something.

its more about fixes that respond to other changes in the eco-system.

I see, so Quarks is really mostly about managing unstable packages, rather than stable ones. I think that makes it more of a tool for developers than for regular users. In fact from what you describe it seems to me what you really want and need is svn itself and a shared repository, and all the Quarks classes really add is an SC interface and easy uninstall.

That's not what I'd thought was the intention, but if that's what the consensus is for then so be it.

It would be nice at some point however to have a package manager for regular users that allowed them to deal with stable packages (tested against the current point release) and that worked out of the box. Perhaps Quarks could be extended to do that as well as the current functionality. I may look at this when I have more time.

For now I would suggest not worrying about extending it for 3.2, as the binary + extensions bundle approach should be fine for most users. 

S.