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...
It is not really the case, because the external projects
are autonomous.
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.
It could be the trick.
But people will have to merge our changes.
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.
So we have
when we integrate from a project a given version
and when we push to the project a symbolic version but it
can lead to some mess, no?
Cheers, Henry
