Squeakfoundation February 2003

squeakfoundation@lists.squeakfoundation.org

22 participants
36 discussions

RE: [Squeakfoundation]Taking control of parts of Squeak
by Daniel Vainsencher 24 Feb '03

24 Feb '03

Like many things in life, it's not complicated, but it's subtle... Berners, I think everyone is curious about you intentions. If you could put out a draft of a "release plan", that'd be good. What do you want to achieve (in detail), what classes/protocols are you targeting, what you want from the community/possible collaborators (Anthony's compiler work comes to mind). Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > Hi Göran, > > > 1. A very small rule set for being a kernel package maintainer. Say, > > about 5 rules? :-) > > I dunno. It seems very hard (at least to me) to come up with a set of rules > here. Something more loosely defined such as "guide lines" might be more > appropriate (this is why I was referring to a "general outline"). > > But let's see. One rule (or rather guide line) which I think is important > for the community is a "controlled rate of evolution". What I mean by this > is that while we expect the kernel packages to evolve as any other part of > Squeak there is always the danger of breaking existing stuff (much more so > than in any other package). I _think_ that this means that larger scale > changes have to be discussed with the community first and that a time line > for deployment needs to be developed prior to making it part of the "core > release". It should give other maintainers enough time to get the changes > integrated and should probably come along with some "migration support" > (whatever this means in the concrete case - it could be automated tools, it > could just be an FAQ). > > Hm ... just thinking about it I think that's essentially the only "rule" I > can come up with. Other than that there seems to be no difference between a > package which is part of "kernel Squeak" and one that isn't. It's really the > aspect of evolution (e.g., rate of change, stability etc) that makes a > kernel package "different" from any other, which effectively means that a > kernel package maintainer needs to be a bit more conservative for her stuff > than Joe-Doe. > > Cheers, > - Andreas > > > -----Original Message----- > > From: squeakfoundation-bounces(a)lists.squeakfoundation.org > > [mailto:squeakfoundation-bounces@lists.squeakfoundation.org] > > On Behalf Of goran.hultgren(a)bluefish.se > > Sent: Monday, February 24, 2003 9:28 PM > > To: Discussing the Squeak Foundation > > Subject: RE: [Squeakfoundation]Taking control of parts of Squeak > > > > > > Hi all! > > > > "Andreas Raab" <andreas.raab(a)gmx.de> wrote: > > > Colin, > > > > > > > However, I don't know that we need to have a big rules > > discussion. > > > > > > True. But I think some general outline of what is expected > > from someone who > > > wants to "take over" a portion of kernel Squeak is good. It > > simply means > > > that there's a common understanding within the community of > > what is expected > > > from a "kernel package maintainer". This can only help as > > we are moving > > > towards a more decentralized model of development. > > > > I agree. > > > > I also agree with Colin that we shouldn't get tangled in trying to > > establish a complicated rule set that noone will follow and just make > > people hesitant of becoming a kernel package maintainer. :-) > > But I think > > we can avoid that. > > > > But again - for a *particular* maintainer to present how he/she/they > > intend to maintain a *particular* package is very good. > > > > So, to be a bit constructive here - I would like the community to > > produce the following: > > > > 1. A very small rule set for being a kernel package maintainer. Say, > > about 5 rules? :-) > > > > 2. Some form of simple process how to become a kernel package > > maintainer, how to stay one :-), and how to move the stick to someone > > else. > > > > And lets stay out of the "technical how" for a bit. We can attack that > > as the next step. So... is this admittedly short list what we need? If > > it is then I can continue by presenting a little draft based both on > > ideas from Roel etc. > > > > regards, Göran > > > > PS. I intend to produce some form of proposal here on this list and > > then, when we agree on it - post it on squeak-dev and see what all > > others think. > > > > _______________________________________________ > > Squeakfoundation mailing list > > Squeakfoundation(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/listinfo/squeakfoundation > > > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

RE: Fw: [Squeakfoundation]Re: Taking control of parts of Squeak
by Andreas Raab 24 Feb '03

24 Feb '03

Hi Guides, [Sorry for the belated reply but the mail server in Berne wouldn't let me send email through it. I just came home so here we go...] I think it's important for the Guides and anyone else to understand that this idea really goes both ways. When we were talking about this in Berne, my point of view was essentially the following: SCG needs an open, extensible, clean kernel for their research work. Squeak needs an open, extensible, clean kernel for its users. What better match is there?! We have the same needs and a group of people willing and able to do the job. By providing that kernel to the Squeak community, SCG gains an interesting "playground" for their research work on and in Squeak, with the ability to experiment with everything, including VM modifications. The Squeak community gains the kernel and the ability to easily play around with any new stuff that SCG develops if that is of interest. Whether any of these developments actually makes it into "core Squeak" is quite a different matter at this point. To me, there is a clear win-win situation if we put our trust into SCG to handle the situation appropriately and not to take overly advantage of the fact that they could in fact change the MOP of Squeak beyound recognition (but hey, isn't that the case for any package on SqueakMap?! after all the maintainers can change it at their own will and pace...). Knowing the people involved I think that this would be a very reasonable arrangement with advantages for all parties involved. Let's not forget - someone needs to maintain these aspects of Squeak and personally I'd much rather see a group of people work on this who actually understands what they are doing and what the community wants and expects out of this work. Cheers, - Andreas > -----Original Message----- > From: squeak-dev-bounces(a)lists.squeakfoundation.org > [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On > Behalf Of Stephane Ducasse > Sent: Sunday, February 23, 2003 8:55 PM > To: The general-purpose Squeak developers list > Subject: Re: Fw: [Squeakfoundation]Re: Taking control of > parts of Squeak > > > Hi all > > Just a point that may not have been made clear enough. We > want to clean > the kernel not change it. For our own business we will certainly come > with a better one but at that time we will see. > > > Stef > >

4 8

Re: official Accufont image?
by Ned Konz 23 Feb '03

23 Feb '03

On Saturday 22 February 2003 09:46 am, Daniel Vainsencher wrote: > About the fonts - I agree. Doug, Ned, how about adding the > AccuFonts package, with an answer of "yes" to the replace fonts > question, as the first update to 3.5alpha, and producing an image > with that update, to create an Apple-font-free official image that > we can bring to the Apple table? We certainly *could* do that; what do the rest of the Guides think? > Ned, when it asks "replace the existing fonts?", can we be fairly > certain there's no trace of them left in the image? I'll check. One of the things that I find with the version on SqueakMap is that the default text font needs to be changed to make it somewhat bigger after installation (to make it similar in size to the NewYork that was being used). We could add that to the installer. -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

2 1

Re: Taking control of parts of Squeak
by goran.hultgren＠bluefish.se 21 Feb '03

21 Feb '03

Hi Roel and you all down there in Bern! Roel Wuyts <roel.wuyts(a)iam.unibe.ch> wrote: > Hi Goran, > before mentioning anything on the list I'd like to discuss some views > we have here on how the decentralization of responsibility of Squeak > could be done. Sure, I took the liberty of CCing this onto the SqF list since that is "Guide territory". > To make it concrete, we are deciding whether or not we will propose to > become the responsibles for the meta-programming/reflection part in > Squeak (ClassBuilder, ...). [Note that this is about base image parts, > not about 'optional' things like StarBrowser, etc.] Our motivation is Right, sounds very good to me. You are pretty strong in that department and you are also driving much of the development there currently. > that in order for some of our research, we need to change this anyway. > So we might as well give this back to the community. However, in order > for us to do this, we think that some structure should be put in place > first: > - there has to be a clear boundary about what the part of Squeak > contains that you become responsible for. Right. For packages in general it is pretty obvious but for parts that perhaps never will move out from the kernel (like the parts you are talking about) the boundaries need to be "declared" somewhere. > - this part of the system needs to be fully documented with unit tests > (at least) or whatever other documentation is needed otherwise (I take > a pragmatic view in this whole documentation discussion). Right. > - the unit tests have to be available for download via Squeakmap etc. > so that anybody can try them. Yes, those are indeed suitable as one or more packages on SqueakMap. And frankly, we can register the core parts as packages too - for "mapping" reasons. It is good to see maintainer, homepage, version etc even if the package itself really can't be broken out of the core image. And later I am envisioning stuff like linking bugreports, updates etc to the packages so having a package registration is in itself good. > - all changes to the part that you are responsible for, can only be > approved by you. Yes, that is the idea with responsibility! :-) > - anybody who wants to update something in your part, has to download > the unit tests, make the change, and can only submit a patch that runs > with these tests. Then the maintainer has the responsibility to include > this patch, after some more reviewing internally, or reject it. Now you are discussing the development process in detail and even if I sympathize with the goals there are many different ways of doing this in practice. For example, the new Harvesting tool was intended to be "package aware" and tus have multiple "production lines" where FIXes/ENHs etc are lined up for review, test, modification and eventually inclusion into the package. But anyway, I agree. If there are unit tests available, patches will only be considered if they are green with them. And I also agree that the maintainer has a responsibility to consider all contributions. > - bugs are submitted as failing testcases (ideally). Or they can also > be submitted in text, but only in rare cases (very hard setup, etc.). Guidelines, sure. > New tests have to be added that reflect the fixed bug. Right. > PS: This mail is from all of us in Bern. But I was chosen as > communication medium :-) I hope it is a bit clear what we mean :-) > > PS2: We are still deciding what we will do, but a bunch of guidelines > like this should be put in place anyway. > > PS3: Feel free to distribute this mail wherever you think it is useful. I am all in favour of: - Laying out the "rules" for how we distribute "maintainership". - Actually starting to dish out parts. As we are all aware of - the social mechanisms within the community are very important to take into account. Therefore I think it is important that we agree on how this "maintainership" is decided and what responsibilities comes with it. But it should of course still be a "fun thing to do" - after all, we are driven by the fun of it all in the end. :-) regards, Göran

1 0

3.4 release
by Doug Way 21 Feb '03

21 Feb '03

As the new update stream guy (and, by association, the guy in charge of getting releases out the door), it's time to release Squeak 3.4! (Sorry for falling a few days behind on this.) To help clarify the process for me and everyone else, I wanted to give a quick overview of the release timeline, to make sure I have the right idea. Here are the steps: 1. Mark the image as 3.4 final, and upload a copy of the final image to the ftp site. Immediately afterward, announce this to the squeak-dev list. 2. Within a few days (?), have the 3.4 VMs uploaded to the ftp site. This should include a Windows VM, a Mac (Carbon) VM, and the sources (?) for the Unix VM, and possibly at least one pre-built Unix VM. (Which one(s)? Probably Linux at least.) Also, pre-packaged zip/stuffit files containing the VM/image/changes/sources files should be made available on the ftp site for Windows & Mac. 3. Shortly afterward, the http://squeak.org download page should be updated so that it points to the 3.4 files instead of 3.2. 4. After that, the release of Squeak 3.4 can be announced to the rest of the world. (Slashdot, etc. See the External Relations SqF wiki page.) Does this sound about right? The only questions I have are: - Should we wait a few days between steps 1 and 2? This would let people test the final image a bit just to make sure there wasn't some major problem, and maybe check out any final cosmetic tweaks. Also, it would give the VM maintainers a few days to get their VMs ready. But perhaps this isn't necessary... maybe we should make sure the VMs are ready before we declare 3.4 final. (Certainly they should be almost ready anyway.) - Which Unix VMs should be available immediately upon the release of 3.4? Sources? A Linux VM? Debian and/or RPMs? Obviously we don't want to wait around for lots of lesser-known Unix variant VMs to be compiled. (PDA's and other platforms' VMs can be made available later, too.) I think I have a good idea of who is responsible for most of the above. Scott/myself for step 1, Andreas/John/Ian for providing the VMs, Bruce (or myself) for updating the ftp site and squeak.org site, and Cees for announcing to the rest of the world. (Do we still need someone to create Debian/RPMs if we want those?) Anyway, we should probably move ahead with step 1 in the next couple of days, but before doing this, I'll check with the VM maintainers & others to make sure we can move ahead with the rest of the steps. Also need to look at the image tweaks that Tim mentioned a few days ago. - Doug (btw, thanks to Alejandro Magistrello for filling out the "already incorporated" items on the swiki harvesting tables)

8 33

Re: [Squeakfoundation]identifying existing apps to package
by Daniel Vainsencher 14 Feb '03

14 Feb '03

Hey guys. Okay, a bit about what SpT does: First it creates a graph where classes are nodes, and dependencies are links. Depedencies are either Classes references, or subclassing. Then it finds all the cycles in the graphs at once - this is called strong connected components. Why are cycles important? because they show precisely where things are misengineered. If Morph depends on Object, that's fine, but if they both depend on one another... that's a problem. To extract interesting information, we compare the cycles in the graph to invented module boundaries (like class categories, or DVS package boundaries). Where a cycle crosses the module boundaries, we know we need to refactor things (we need to cut at least one of the directions of dependency). Did this make sense? does it sound like what you're looking for, Ned? if so I'll go into more details.. Daniel Vainsencher Ned Konz <ned(a)bike-nomad.com> wrote: > On Wednesday 12 February 2003 07:13 pm, Avi Bryant wrote: > > On Wed, 12 Feb 2003, Ned Konz wrote: > > > I'd like to start the packaging process for parts of the 3.5 > > > image, as planned. > > > > > > I know Daniel and others have written tools for static analysis; > > > I was hoping someone could come up with a good way to actually > > > discover the contents of the different packages (strongly coupled > > > clusters of otherwise independent classes along with class > > > extensions that they use or that refer to them). Plus, I'd like > > > to get the names of the major writers of the existing code. > > > > Ned, > > > > The hard part, I think, is associating class extensions with the > > right package. I added some dependency queries to PackageInfo as a > > step towards being able to do this; > > PackageInfo>>browseExternalReferences is particularly useful when > > trying to carve out the image manually, but I never got anywhere > > with an automated tool to do this. My vague thought was that any > > external references to that package (ie, methods that use that > > package's methods or classes) could be evaluated for inclusion in > > the package, and brought in if that would make the package have > > fewer external references in total. After a few iterations this > > ought to converge on some kind of rough approximation of the right > > methods, I hope - but I've never tried it. > > > > Is that the kind of tool you were thinking of? > > Yes. I think Spaghetti Tracer can do some of this. > > -- > Ned Konz > http://bike-nomad.com > GPG key ID: BEEA7EFE > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: [Squeakfoundation]identifying existing apps to package
by Daniel Vainsencher 14 Feb '03

14 Feb '03

Doug Way <dway(a)riskmetrics.com> wrote: > > On Wednesday, February 12, 2003, at 09:58 PM, Ned Konz wrote: > > I'd like to come up with a table in HTML that lists: > > * Category > > * Class names > > * Major authors > > * Last period (quarter year?) in which substantial changes were made > > * Outside dependencies > > > > And I'd like to do this automatically, if possible. This could also be useful for a future project dealing with clearing up licensing. > > Then we can start signing up volunteers to pick these apart. > > Yes. There's also this page at: > http://swiki.squeakfoundation.org/squeakfoundation/77 (which you > probably already know about) Actually, we should make sure this page > stays up to date, too... for example, the IRCConnection refactoring is > already in the image, I believe, so it should say "integrated"; it > could now be removed. Agreed. I think it's better to leave it there as integrated, to remember the progress we've made. > > Once we have tools and HOWTO manuals on package stripping, we should > > be able to get more volunteers. > > > > Some relatively easy targets that I can see: > > > > * Speech > > * Fabrik > > * Games > > * Piano Roll > > * Process Browser > > * Archive Viewer > > * eToy communications and Nebraska This one might not be as easy as it seems - I used SpT one it once, and discovered that Morph is dependent on it. Of course the links might seem simple enough to cut on further examination. > > * Scamper > > * VM Construction Daniel

1 0

identifying existing apps to package
by Ned Konz 14 Feb '03

14 Feb '03

I'd like to start the packaging process for parts of the 3.5 image, as planned. I know Daniel and others have written tools for static analysis; I was hoping someone could come up with a good way to actually discover the contents of the different packages (strongly coupled clusters of otherwise independent classes along with class extensions that they use or that refer to them). Plus, I'd like to get the names of the major writers of the existing code. Ideally, this is something that we'd apply to an image that has as many change sets in it as possible (to get the historical version information). So if someone has (say) a 2.8 image that they've updated all the way to 3.5a, it would be the ideal test case. I'd like to come up with a table in HTML that lists: * Category * Class names * Major authors * Last period (quarter year?) in which substantial changes were made * Outside dependencies And I'd like to do this automatically, if possible. Then we can start signing up volunteers to pick these apart. Once we have tools and HOWTO manuals on package stripping, we should be able to get more volunteers. Some relatively easy targets that I can see: * Speech * Fabrik * Games * Piano Roll * Process Browser * Archive Viewer * eToy communications and Nebraska * Scamper * VM Construction Harder ones: * Genie * Active Books * eToys * Browsers * File List * MVC * Morphic Any ideas? -- Ned Konz http://bike-nomad.com GPG key ID: BEEA7EFE

4 4

Re: [Squeakfoundation]A bit about SM1.1 and dependencies
by Daniel Vainsencher 13 Feb '03

13 Feb '03

Ah, I see what you envision now. I don't actually see changing the configuration package as a problem - I do trust you'll give an api to do this soon, and then code can do it for me. And as you say, it might be wise to have alternative configurations for the same package. There's no conflict - the alternatives can certainly live inside the package. We agree the depedencies should be outside the code packages, the difference is whether to keep them in a "special place" - resources, or in packages themselves. Simplest thing that could possibly work? > It is not what I want to have for resolving complex dependency networks. > They are two different things and they are needed both IMHO. Aha - we may be addressing different requirements. I'm addressing precisely this problem - I want packages to be modular, I want users to be able to load a package with it's prerequisites, I want maintenance of configurations to be separate from maintenance of code. Either solution does all of these (haven't changed my mind about any of these). I'm not looking for anything more complicated, among things because I'm hoping to make a working release within days of having an SM that supports package releases, for many good reasons mentioned before. What additional needs are you addressing? (elaborate on complex analysis...) > > And I don't see many ways to go around that... > What? I didn't understand this. I'm simply pointing out that when a code package is updated, a human will have to evaluate it to update the configuration. That's the main thing humans maintaining configuration (not code) will have to do, and that's the same between both proposals. How that translates to changes in the metadata itself, I don't care much about - it can be mechanized, either way. I think the models we're proposing are very similar, mine is just minimal and maybe a little crude, but I think it can take us a pretty long way. And the two systems can definitely coexist, and probably even interoperate (you can depend on my kind of package, a vice versa). Daniel goran.hultgren(a)bluefish.se wrote: > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > goran.hultgren(a)bluefish.se wrote: > > > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > > > Ok, just to show what I mean. Suppose I make a package type that holds a > > > > single method that goes something like > > > > ^#((RBModel 1.09) > > > > (RBGUI 1.06) > > > > (RBTests 1.05)) > > > > > > > > Then I write a service that loads this kind of package, and does > > > > packagesList collect: [:packagePair | SMSqueakMap loadPackage: > > > > packagePair first version: packagePair second]. > > > > > > > > Or maybe something a little more complicated, but you can see where I'm > > > > going... I don't need much more support. > > > > > > Ok, this looks to me like "virtual packages". A package that has no > > > content and loads specific versions of other packages. In fact - this is > > > a "static load script" given my previous terminology. (Static in the > > > sense that it will always result in the same package releases being > > > loaded) > > Not exactly - note that the code interpreting the list is outside the > > list, in a service. The code here is just a way to store the > > instructions. > > Sure, but what real difference does that make? It is still a list of > specific releases of other packages to be installed. Or? > > > > But this plan doesn't AFAICT make it possible to have multiple possible > > > configurations for RB. I assume that the virtual package/load script you > > > described above would be "RB". > > Actually it does - there's nothing stopping me from concurrently also > > publishing another package that also specifies the RB Components, at > > different versions. For example - > > ^#((RBModel 1.1)(RBGUI latest)(RBTests latest)(RBRewriteRuleEditor > > latest)) > > Sure, I understand that you can publish several different "load > scripts". > But that would in fact be *different* packages. Of course you would give > them names like "RB cool" and "Another RB" etc. But that wouldn't help > the dependency engine at all. > > Let me reiterate: I want to be able to have different working > configurations for one specific package release. For example, one > "certified working configuration" is that RB1.2 works if SmaCC1.1 and > SUnit3.3 are in the image too. BUT... RB1.2 may also be able to work > just fine with SmaCC1.2 and SUnit3.3. That is another fully valid > configuration for RB1.2. > > The idea here is that an engine can analyze these multiple > configurations. And adding a new configuration (registering a Resource > and linking it to RB1.2) does not change the version of RB. > > > could represent the right configuration for someone that want to play > > with the latest GUIs, but using a known stable model. The two can > > definitely coexist - each is it's own package (I don't know what you > > mean by virtual), and even be authored by different package maintainers. > > Yes, I fully agree that this is useful for exactly the thing you > describe. But that is a "load script" package. > It is not what I want to have for resolving complex dependency networks. > They are two different things and they are needed both IMHO. > > > > It would also mean that you need to make a new version of RB if you want > > > to change the dependencies for RB - so you get "cascading version > > > changes" - package Y is released in a new version and X depend on it so > > > must also be released in a new version etc. etc. > > No, why? > > The only time I'll have to update depedencies, is when I have a stable > > configuration, and I've decided that a newer version deserves to be > > point to in it. And I don't see many ways to go around that... > > What? I didn't understand this. Ok, let's say you have registered a > "load script" called RB version 1.0 that contains information about what > other package releases should be loaded - package X1.1 and Y3.4. > > And then I release package X in version 1.2. You realize that, hey - RB > works dandy with this newer release of X. So what do you do? Ah, you > need to *change* package RB. And if you change it then you better change > the version too. > > In my scheme you would simply just register another configuration and > link it to RB1.0 - this simply says: Hey, I just tested RB1.0 with these > packages too and it still works. So the dependency engine now has two > working versions of X that it can choose from without making RB1.0 go > bonkers. And that is very good since package Z that I want to use > together with RB1.0 may actually *demand* X version 1.2. > > Well, I have been describing these things so many times now that I > simply need to implement them. :-) > > I mean - it was you who pushed me in this direction by saying that the > dependency information should be *outside* the packages in order to be > able to have them evolve independently. Those emails we exchanged has > influenced my model a lot. And now you are arguing IMHO in the opposite > direction. ;-) > > Sidenote: I did run my model by Roel Wuyts, Doug Way, Stephen Pair and > several others I can't remember right now at OOPSLA and they all liked > it. This also included the draft on how the dependency engine will use > this information to resolve complex situations and my concept of > "stretchable dependencies". > > regards, Göran > > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Re: [Squeakfoundation]A bit about SM1.1 and dependencies
by Daniel Vainsencher 12 Feb '03

12 Feb '03

goran.hultgren(a)bluefish.se wrote: > Daniel Vainsencher <danielv(a)netvision.net.il> wrote: > > Ok, just to show what I mean. Suppose I make a package type that holds a > > single method that goes something like > > ^#((RBModel 1.09) > > (RBGUI 1.06) > > (RBTests 1.05)) > > > > Then I write a service that loads this kind of package, and does > > packagesList collect: [:packagePair | SMSqueakMap loadPackage: > > packagePair first version: packagePair second]. > > > > Or maybe something a little more complicated, but you can see where I'm > > going... I don't need much more support. > > Ok, this looks to me like "virtual packages". A package that has no > content and loads specific versions of other packages. In fact - this is > a "static load script" given my previous terminology. (Static in the > sense that it will always result in the same package releases being > loaded) Not exactly - note that the code interpreting the list is outside the list, in a service. The code here is just a way to store the instructions. > But this plan doesn't AFAICT make it possible to have multiple possible > configurations for RB. I assume that the virtual package/load script you > described above would be "RB". Actually it does - there's nothing stopping me from concurrently also publishing another package that also specifies the RB Components, at different versions. For example - ^#((RBModel 1.1)(RBGUI latest)(RBTests latest)(RBRewriteRuleEditor latest)) could represent the right configuration for someone that want to play with the latest GUIs, but using a known stable model. The two can definitely coexist - each is it's own package (I don't know what you mean by virtual), and even be authored by different package maintainers. > It would also mean that you need to make a new version of RB if you want > to change the dependencies for RB - so you get "cascading version > changes" - package Y is released in a new version and X depend on it so > must also be released in a new version etc. etc. No, why? The only time I'll have to update depedencies, is when I have a stable configuration, and I've decided that a newer version deserves to be point to in it. And I don't see many ways to go around that... Daniel Vainsencher

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation February 2003