- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephan Eggermont

Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > It is clear that we need both baselines for that case. > But because we will move Calypso to Pharo repo I think it is easy to manage > strong versions directly in Pharo loading script for now (in #loadCalypso > method). Easy for now, yes. And also a bad example for others to follow. And something that doesn't scale. Where is the increased modularity going to come from if we still manage everything as a monorepo? Stephan

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Dale Henrichs

Cyril, For development I tend to use Metacello locking instead of hard-wired dependencies in the BaselineOf and that works very well --- it completely avoids the need to edit a baseline for development purposes and this approach works really well for me ... perhaps we can discuss this in more detail in a separate thread or even private email? This all seems to be more complicated for you guys than has been my experience and of course you guys _appear_ to be completely ignoring the Metacello locking feature so I'm curious why ... Dale On 03/05/2018 08:02 AM, Cyril Ferlicot wrote: > > On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@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". Since it's stable, BaselineOfMaterialDesignLite should > depend only on fixed version of the dependencies. For example it > should depend on MaterialDesignColor "v1.0.0". > 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

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

2018-03-05 18:23 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >... > > > > 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 strongly advice against using Baselines for that. They are supposed to be > edited from hand, and using them for reproducible versions will break other > projects, as we've seen earlier with Configurations. AFAIK Metacello can > register which versions were loaded in which order, so that information > should be recorded for reproducibility. > It is clear that we need both baselines for that case. But because we will move Calypso to Pharo repo I think it is easy to manage strong versions directly in Pharo loading script for now (in #loadCalypso method). > > Stephan > > > > > > > >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Nicolas Cellier

2018-03-05 18:23 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >... > > > > 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 strongly advice against using Baselines for that. They are supposed to be > edited from hand, and using them for reproducible versions will break other > projects, as we've seen earlier with Configurations. AFAIK Metacello can > register which versions were loaded in which order, so that information > should be recorded for reproducibility. > > Stephan > > > I support the idea of Stephan to go thru a two steps process: - use Metacello to extract exact versions - store this information as the specification of the bootstrap version. Can Metacello perform a sort of dry run? If not, would be nice! Then a UI with such information would be nice too (to answer the question: what will be loaded exactly, and from where?).

March 5, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

by Stephane Ducasse

Thanks pavel such experiments are super interesting because they push us outside our confort zone. On Mon, Mar 5, 2018 at 10:29 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > Guille is working on the Iceberg improvements and he wanted to be able to > open a terminal window on top of the repository and interact with it via > the command line. So we looked at this issue because I already in December > made some experiments with the terminal emulation in Pharo. > > In past, the Squeak had a working terminal emulation that used > PseudoTTYPlugin. The VM is not built with this code for a long time but I > tried to replace it with a small C library and then wrote an FFI interface > to it. Together with that, I ported most of the old code Squeak code to > Pharo. > > With Guille we tried to avoid usage of such external library and wrote an > FFI interface to all the required LibC functions. We were successful but we > realized that there are several issues that are limiting us. > > When you want to execute a separate process for the program that you want > to open in terminal (typically the Bash), you need to redirect the standard > IO files, create a fork of your process, do some additional initialization > in it and call 'exec' on it. In the parent process, you change redirected > IO files back to the original values. > > But the problem is that between the FFI calls from Smalltalk the VM can do > a lot of things including garbage collection etc. On OS X the fork() > function has the following limitation described in man: > > "There are limits to what you can do in the child process. To be totally > safe you should restrict your yourself to only executing async-signal safe > operations until such time as one of the exec functions is called. All > APIs, including global data symbols, in any framework or library should be > assumed to be unsafe after a fork() unless explicitly documented to be safe > or async-signal safe. If you need to use these frameworks in the child > process, you must exec. In this > situation it is reasonable to exec your-self. yourself." > > > As the result in most cases (but not all) the fork() and exec() pair from > the Smalltalk side fails on OS X. Linux does not have this limitation > however even there we found an issue. It is bound to the fact that fork() > makes a fork of all the parent process that uses the same resources. As > soon as Pharo is opened in a window and X11 is involved (the window wants > to be repainted), it can lead to the VM crash. > > So we learned that unfortunately we currently cannot use image-only FFI > code for this task. We need a C library or VM plugin. > > The repository of the terminal emulator is here: https://github.com/pavel- > krivanek/terminal > > and can be loaded using the following code: > > Metacello new > baseline: 'TerminalEmulator'; > repository: 'github://pavel-krivanek/terminal/src'; > load. > > #TerminalEmulator asClass compileLibrary. > > > â > It compiles and links the small library with only one function using the > GCC so the machine needs to have a proper development environment. > > The terminal emulator is in very early stage and has a lot of issues like > processes cleanup, drawing, keyboard input etc. etc. If you are interested > in it, feel free to contribute. > > Cheers, > -- Pavel > > > > > > > >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephan Eggermont

Guillermo Polito <guillermopolito(a)gmail.com> wrote: >... > > 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 strongly advice against using Baselines for that. They are supposed to be edited from hand, and using them for reproducible versions will break other projects, as we've seen earlier with Configurations. AFAIK Metacello can register which versions were loaded in which order, so that information should be recorded for reproducibility. Stephan

March 5, 2018

Re: [Pharo-dev] The 6.1 Space Monkey is unhappy

by Stephane Ducasse

On Mon, Mar 5, 2018 at 2:29 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > 2018-03-05 14:14 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> Hi pavel >> >> when I'm back can you explain to me because I did not get it :). > > :) it is simple. If you want to ignore issues that the slice is not > adding, you need to know which of them to ignore. That's why the > original monkey run all the validations twice - first time to collect > a list of failing tests in the fresh unchanged image and then with the > slice or configuration loaded. So it doubled the issue validation > time. It sounds good :) > There are several alternative strategies like to cache the failing > test results for every build and use them for validations but the best > strategy is simply to keep the amount of failing tests in the clean > image on the zero level and force people to keep the system clean. Yes! > The > original monkey hasn't exposed the list of ignored tests. So it was > possible that some test was ignored because of a temporal network > issue but for the second time it failed for o good reason and you even > didn't know. > > Cheers, > -- Pavel > >> >> Stef >> >> >> On Mon, Mar 5, 2018 at 11:07 AM, Pavel Krivanek >> <pavel.krivanek(a)gmail.com> wrote: >>> 2018-03-05 10:54 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: >>>> >>>> >>>>> On 5 Mar 2018, at 10:27, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>> >>>>> Hi Marcus, >>>>> >>>>> On 5 March 2018 at 09:23, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>>>> >>>>>> >>>>>>> On 5 Mar 2018, at 09:16, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>>>>>> >>>>>>> Hi Esteban & Marcus, >>>>>>> >>>>>>> I'm getting repeated validation failures for: >>>>>>> >>>>>>> https://pharo.manuscript.com/f/cases/21431 >>>>>>> >>>>>>> >>>>>>> It's the same set of tests that fail each time, and as far as I can >>>>>>> tell they have nothing to do with the patch I submitted. >>>>>>> >>>>>>> Do you know if this is happening on other tests? >>>>>> >>>>>> I saw that Saturday but decided to wait till Monday (weekends are important..). >>>>>> >>>>>> So: no, I have *no* idea what happened. From one CI run to the next, >>>>>> suddenly around 160 tests related to Calypso started failing due to a missing method. >>>>>> >>>>>> Now starting from sometime today, this problem stoped. The last failing PR checks >>>>>> fail due to different reasonsâ¦ >>>>>> >>>>>> And I have no idea why. >>>>>> >>>>>> (And yes, we al know that >>>>>> 1) the PR checks need more compute power, too slow >>>>>> 2) we *need* to track down the reason why still *a lot* of times the PR fails >>>>>> even though it should not. >>>>>> >>>>>> The problem is that just keeping a build alive of this kind is a full time job.. that >>>>>> we have nobody doing, so many many people do as much as they can and we >>>>>> hope it will get betterâ¦.) >>>>> >>>>> Thanks for the update. >>>>> >>>> >>>> Oh, and it was completely unrelated. Your change is for Pharo6... >>>> >>>>> I took a look at the failures and it appears that >>>>> >>>>> BehaviorTest>>testBehaviorRespectsPolymorphismWithTraitBehavior >>>>> ClassDescriptionTest>>testClassDescriptionRespectsPolymorphismWithTraitDescription >>>>> ClassTest>>testClassRespectsPolymorphismWithTrait >>>>> >>>>> are all failing due to changes in Fuel - methods were changed from >>>>> traits to local methods. >>>>> >>>> Yes, the problem is that the monkey (the contribution checker) fails as soon >>>> as there are errors even in the main image. >>>> >>>> The last Pharo6 has these tests failing, so now all contribution checks for >>>> Pharo6 fail. >>>> >>>> What needs to be done? >>>> >>>> -> your change can be accepted as we know it does not fail more fixes >>>> -> then we need fix the tests in Pharo6 >>>> -> in a perfect world we would update the slice checker to only fail for >>>> now test failingâ¦ (it used to be lille thatâ¦). >>> >>> I must say that It made the validation two times slower, fragile and >>> led to the hiding of problems instead of solving them... >>> >>> -- Pavel >>> >>>> >>>> As I said: this is a full time jobâ¦ >>>> >>>> Marcus >>> >> >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephane Ducasse

On Mon, Mar 5, 2018 at 6:07 PM, Guillermo Polito <guillermopolito(a)gmail.com> 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 <dionisiydk(a)gmail.com>: >> >>> 2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: >>> >>>> >>>> On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito < >>>> guillermopolito(a)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 <+33%206%2052%2070%2066%2013> >

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Guillermo Polito

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.nice(a)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 <dionisiydk(a)gmail.com>: > >> 2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: >> >>> >>> On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito < >>> guillermopolito(a)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

March 5, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Nicolas Cellier

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 <dionisiydk(a)gmail.com>: > 2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > >> >> On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito < >> guillermopolito(a)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 >> > >

March 5, 2018