On Tue, Mar 3, 2015 at 11:36 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-03-03 16:06 GMT+01:00 Ben Coman <btc@openinworld.com>:
On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Ben Coman wrote
Would it be feasible to have a community maintained PharoForwardCompatability package available in the ConfigurationBrowser that is generally available for everyone to use
Great idea! If we're just talking about renames, it could just be pre-loaded, no?
Ideally these sort of renames would be pushed back to all previous Releases, but that seems not feasible resource-wise. Its a question of ALL actions required do a point-release of those older versions, and how often you are able to do that. There is also the temptation that with a point-Release, people will pressure to add "just one more" thing that might not be a "simple rename" .
An additional benefit of it being a Configuration loaded external onto the older Releases is that people can see the changes, which is a big tip for which parts of their code the should update for it to work in a later version.
Ben, I like your idea.
It would allow stable-based additional packages to include the . configuration as a pre-requisite (and as such make the manager of that package aware that it has a version working on the .1 or the .2 version).
For example, I could have a SmaCC v2.0.3 for Pharo3.0, a SmaCC v2.0.3.1 requiring ConfigurationOfPharo3.1, and switch my #stable to v2.0.3.1 (for example) any time after ConfigurationOfPharo3.1 became available.
My idea might have merit to do point releases of PharoX.x, but I think the semantics of that are broader and likely a bigger effort than what I was considering, which was having a ConfigurationOfPharoForwardCompatability. cheers -ben