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.

The strong point is: if I don't see the need, then my SmaCC will stay at v2.0.3 for Pharo3, and will keep working even if ConfigurationOfPharo3.1 makes obsolete a key API I do use, since, by default, pharo users will download the 3.0 image.

ConfigurationOfPharo3.1 should change the platform tag to #pharo3.1. To avoid that someone updates his image to 3.1, load my SmaCC planned for 3.0, and encounter errors that I don't want to handle (yet).


Also because people using the package can see the "simple" changes, there doesn't need to be as much rigor adding stuff to it - so it can be more community driven.� Also its more dynamic - for example if this change is made early in Pharo 5, the Pharo 4 projects can already include it and be already adapting. Because you want to minimise the point releases of the older versions, you would otherwise need to wait a whole year for the Pharo 5 Release to lock down all required "renames" to back propagate.�

Also, one of the points of that scheme is that those additional packages are entirely optionals: by default, there is no point release.

Or, if we need the possibility to have a point release of Pharo in the stable cycle, we can call the point release .0.X (and have the platform naming follow suit).

Example:

Pharo3.0 released. (#pharo3.0.0)
ConfigurationOfPharo3.1 released (#pharo3.1.0)
ConfigurationOfPharo3.2 released (#pharo3.2.0)
ConfigurationOfPharo3.3 released
Pharo3.0.1 released with bugfixes (say it is judged necessary) but no API change. (#pharo3.0.1)
ConfigurationOfPharo3.4 released

etc...

Approach being: 3.0.x is supposed to maintain a stable api (no change needed for external packages)
3.X is optional and mark/prepare changes for 4.0

How hard it would be to keep the Monkey checking on past versions of Pharo? Can I provide a SLICE for Pharo3 now and the monkey is able to say if it passes or not? I haven't tried.

Thierry