That's fine ... but then it should be a separate thread ...
Dale
On 03/05/2018 11:16 AM, Stephane Ducasse wrote:
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
