Yes and no. I think I kind of get it now from all comments... There are two problems together, one is how to reproduce the loading of a project (or getting a working version), and the other is how to use metacello also to manage the development of the project when the dependencies feel more like subprojects that may be edited altogether...
On one side there is the reproducibility problem. I understand Stephan's and Nicolas' points. Using exact versions may block development. However, I see also that people in general have problems using semantic versioning and getting working versions done. This morning the image was broken because of wrong but "not fixed" dependencies... This afternoon Pablo was blocked executing the bootstrap because iceberg's and the image version did not match and Metacello was not the best friend when resolving a conflict on a package that did not exist on one of the two conflicting versions... So yes, it may block upgrades, but until we have tools that allow us to cope with the complexity, I prefer to have reproducible versions where I can reproduce bugs in a reproducible way than an unpredictable version where I cannot grasp the cause of a problem :/. On the other side, there is the fact that Metacello baselines are so far nice to describe release project dependencies, but they are not so nice to describe subprojects/development dependencies that may get edited along with the parent project. Kind of what we used to do with #bleedingEdge. I feel this is a complex problem, that not even SBT or maven that are there since years are capable of solving nicely... Tode and Iceberg metacello integration try to solve this problem by "ignoring the dependency and using the loaded repository" but this may not be successful either... Now, pushing the complexity to how we manage the Pharo repository is not the solution either :) On Mon, Mar 5, 2018 at 5:51 PM, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > The well known problem with fixed configurations is dependencies: > > My project A version 1.2.3 depends on project C version 4.3 (semantic > versioning). I have tested it with 4.3.35, it works well... > If semantic versioning is correctly used, it should work with any 4.x.y > where x>=3. > There is another project B version 2.1.4 which depends on project C > version 4.4 (still semantic). > > Loading latest patch 4.4.20 should work for both A & B. > And even 4.6.11 which is the latest compatible version in 4.x serie > > IMO, the package ConfigurationOfPackageA and ConfigurationOfPackageB > should NOT specify the exact version of package C, but only the minimal > compatible version. > Then, if you want a reproducible image, that is up to the specific > assembly of package A and package B (let's call it > ConfigurationOfPackageAandBandC) that you should force the specific C > version. > > Isn't it the problem? > > 2018-03-05 17:17 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: > >> 2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <cyril.ferli...@gmail.com>: >> >>> >>> On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito < >>> guillermopol...@gmail.com> wrote: >>>> >>>> >>>> I still do not understand... Also I do not understand your usage of the >>>> term "the merge". Can somebody give a **concrete** scenario? >>>> >>>> I'll try >>> For example the project MaterialDesignLite have two branches that are >>> always here: >>> - master >>> - development >>> >> Each commit on master is a stable release and end up with a tag as >>> "v1.2.2". >>> >> >> I do not agree with this sentence: >> >> >>> Since it's stable, BaselineOfMaterialDesignLite should depend only on >>> fixed version of the dependencies. For example it should depend on >>> MaterialDesignColor "v1.0.0". >>> >> >> Maybe I am wrong of course. But this is what I expect from semantic >> versioning: >> >> If I made project which uses some libraries I want to get latest fixes >> even in my stable version. This is what semantics versioning is about. >> Minor releases are supposed to be safe for dependent projects. >> It is of course question of trust to third parties. But if I do not trust >> them I should fork dependency and use it instead of original one. >> >> On the branch dev, we want to get the patches and possibly the minor >>> versions of the dependencies automatically. In the baseline we then want to >>> depend on MaterialDesignColor "v1.x.x". Thus, we follow the changes of >>> MaterialDesignColor while it's not a major release. >>> Because of this situation, BaselineOfMaterialDesignLite is different on >>> the two branches. Later, if I want to merge development into master in >>> order to release a new version, master will get the >>> BaselineOfMaterialDesignLite with semantic versionning dependencies instead >>> of the fixed dependencies. Before the release I'll need to change the >>> Baseline to get fix dependencies once again. >>> I hope I was clearer. :) >>> >>> >>>> When you release a version, please do not move that version. You should >>>> then create new versions, with new numbers and new code. But never touch >>>> old versions with old numbers and old code. Like that I can download the >>>> same old code using the same old number to get the old version whenever I >>>> want :). >>>> >>>> You can try to do it with branches, tags, different repositories, or >>>> even with zipfiles in mails. I don't care. Just don't modify releases and >>>> I'm happy with it. >>>> >>>> >>>> >>>> >>> >>> -- >>> Cyril Ferlicot >>> https://ferlicot.fr >>> >> >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
