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. cheers -ben
