2015-05-11 14:32 GMT+02:00 Yuriy Tymchuk <[email protected]>: > Can't we have configuration server pointing to the configurations of the > projects in the repos and getting all supported versions of pharo out of > them instead of having a dedicated repo for each pharo version? >
This does not solve one of my problems with configurations: the fact that writing a version is complex (or require a versionner use and makes for very long configurations in the end). Baselines are a lot easier for that. They do not carry old versions in their code, making them less susceptible of having a huge number of lines of code to represent past versions (and rejected / truncated in future pharo releases like it happened with package version history). Thierry > > Uko > > > On 11 May 2015, at 14:06, Thierry Goubier <[email protected]> > wrote: > > > > 2015-05-11 12:15 GMT+02:00 stepharo <[email protected]>: > >> Yes this is important we should think modularly. >> > > This is one of my issues when dealing with configurations: the need to > copy them in many different places (the MetaRepo for each supported pharo > version, the Smalltalkhub repo for the project, github, etc....). > > Now, I write a configuration once and for all, and that configuration > delegates to baselines which are hosted in branch or version specific > repositories (one repo if github, multiple repositories if smalltalkhub). > Metacello/Git inspired workflow ;) > > Thierry > > >> >> >> Le 10/5/15 18:45, Sean P. DeNigris a écrit : >> >> For example, Soup's config was updated to declare a stable version for >>> 4.0. >>> It was committed to MetaRepoForPharo40, but not to PharoExtras/Soup. It >>> was >>> confusing that loading from the config browser worked, but loading via >>> another config as a dependent project did not (since we use the canonical >>> repo in that use case). >>> >>> Specifically, I am asking that if we update a config, and it's not Pharo >>> xyz-specific (i.e. may break other platforms), that we commit back to the >>> canonical repo or notify the maintainer if we don't have repo access. >>> This >>> policy would obviously be especially easy for any project owned by the >>> Pharo >>> team. >>> >>> Thanks :) >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/Request-Feed-MetaRepoForXyz-Configs-Back-to-Projects-tp4825563.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >>> >> >> > >
