Dale no private emails please.
stef On Mon, Mar 5, 2018 at 6:57 PM, Dale Henrichs <dale.henri...@gemtalksystems.com> wrote: > 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 <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". > 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 > >
