> On 24 Apr 2015, at 8:41 , stepharo <steph...@free.fr> wrote: > > I understand the point of marcus but still it is unclear why certain tools > should be in and not others. > Now I would prefer that we have a process that > > 1 := take a miniimage AND load the tools > check that we can unload them (just to check) > and only then declare > > pharo := 1. > > Now we will face the problem of ok we do a change and it touches such > loaded tools (see the other thread) > Read the Pharo vision paper. > > Stef
The problem with Pharo-Dev in olden days wasn't that no one used the image, but that there was no good process for pushing required updates to "external" packages, so it was more convenient to just develop in the Core image, and leave the other packages for their maintainers to update at the end of a cycle. I don't think the best answer is to pull more and more packages into the Pharo "Core" repository and effectively do double versioning, as seems to be the trend lately... Why not require write access to repositories of external projects that are included in a Pharo-Dev image? Then you can have the Pharo team responsible for a (currently) #Pharo5 symbolic version in the Configuration. Then, when merging slices, push updates to external repos as appropriate (updating #Pharo5 version in Conf), and build new Dev image from a list of such approved Configurations. Lets the external developer do improvements against a static version, and merge with latest non-release when appropriate without leaving the comfort of a single repository. Cheers, Henry
