Salut Francois
We've been bitten a few times at Ta Mère by the problem of changing
metacello configuration.
I agree. This is why I also think that released should point to version
and not symbolic version.
What I do is that we can use versionner to release more often
configurations pointing to the versions.
Christophe will continue to improve it.
At the moment, we rely on the policy of "you should never change a
Metacello version once it has been published". Of course this is
fragile and we've ended up with different code loaded in different
environment while we were expecting stuff to be identical.
Has anyone already tempted to centralize configurations/package in a
read-only place (S3? Azure Storage?). Something like RubyGems or
similar. It may be completely stupid to have centralised system but
I'm not satisfied with the infastructure supporting our configurations.
Am I the only one having this problem? How do you handle it?
We are discussing in the team
- I was thinking that each project/package should have its own
configuration saved in his repo.
-- then the developer may choose to publish it to a central place.
- other are telling to me that other language have a central place.
This is ok too.
I would like to have a catalog of frozen versions per pharo version. Now
this is two years that we request an engineering
to build a project validator and a catalog but we failed.
Stef
