On Mon, Mar 5, 2018 at 6:07 PM, Guillermo Polito <[email protected]> wrote:
> 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 :/. > I understand the point of not hardcoding version but for the bootstrap I think at reproducibility is key. > > 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 > what is SBT and how maven solves it? > 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.nice@ > 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 <[email protected]>: >> >>> 2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <[email protected]>: >>> >>>> >>>> On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito < >>>> [email protected]> 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 <+33%206%2052%2070%2066%2013> >
