2015-03-03 17:00 GMT+01:00 Ben Coman <[email protected]>: > > > On Tue, Mar 3, 2015 at 11:36 PM, Thierry Goubier < > [email protected]> wrote: > >> >> >> 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. >> > > 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. >
But my ConfigurationOfPharo3.X are your ConfigurationOfPharoForwardCompatability. They are just numbered so that they can be relied on for deployment of large packages (and they manipulate a bit the platform so that everything works properly, that's all). Point releases of Pharo are optional. Thierry
