2015-03-03 16:06 GMT+01:00 Ben Coman <[email protected]>: > > > On Tue, Mar 3, 2015 at 10:40 PM, Sean P. DeNigris <[email protected]> > 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
