[Pharo-project] What should be in a configuration?
dhenrich at vmware.com
Fri Jan 6 14:55:53 EST 2012
Obviously, this post is inspired by the 'About ConfigurationOfXMLSupport' thread on the pharo list. Many of the issues with ConfigurationOfXMLSupport are mired in a history that goes back to the very beginnings of Metacello. In the end ConfigurationOfXMLSupport is what it is...
When it comes to what should be in a configuration, my opinion is that each project on SqueakSource should have a configuration. If it is worth having a separate project on SqueakSource, then it is worth having a configuration. Yes, even if there is only one package in the project it should have a configuration.
The reasoning is simple:
- projects evolve over time
- as projects grow, eventually it makes sense to split the project into
- as projects grow, they are ported to other platforms and not all ports
can be done without writing some platform specific code that needs to
be packaged in a separate package
- as projects grow, they become dependent upon other projects ...
- over time the support for a project on VERSIONS of a platform change.
Support is dropped for one version and added for another
- over time the project API changes and not everyone can immediately move
to the new API
- over long enough periods, projects move from one repository to another
Configurations were invented to address these problems and some of these problems exist no matter how many packages or dependent projects are involved.
If I use a configuration to load the code from a project, all I have to worry about is which version of the project I want to use. When I see a new version is available, I can control when I load that new code and be assured that the code won't move out from under me ...
Remember the message from the Metacello presentation that Mariano and I gave at ESUG 2010:
Configurations are NOT for the DEVELOPERS of a project but for the USERS of a project
More information about the Pharo-dev