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.