Hi Dale. Where to read about locking?
2018-03-05 18:57 GMT+01:00 Dale Henrichs <[email protected]>: > 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 < > [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". 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 > > >
