Metacello locking system

Hi Dale,

As asked I start a new thread.

I can see some possible reasons I do not use Metacello locking feature.
1) I did not understand well enough what it was
2) We have a way to work different and mine might be incompatible with
the lock feature
3) I just did not see how it could help me

To know which one is the reason I'll present you a little what I
understood of the lock feature and how I usually work and you'll be able
to advise me.

For the lock feature:

If I understood correctly it is a feature allowing to lock a certain
version of a project in the Metacello registry. For example if I load
Seaside 3.1, lock it and then install a project having Seaside 3.2 as
dependency, the lock will block the update of Seaside.

Now how do I usually work:

Let's take the example of MaterialDesignLite that I maintain.

The master branch is a branch that should only contains stable MDL
versions. Ideally I would like for each commit of this branch to be
tagged with a semantic versionning tag.

The development happen in the development branch and new features are
merged into this branch before making it to master.

In general I prefer to have stricter dependencies in master than in
development. So the baseline in the development branch can be different
than in master.

For all my projects I try to have a Jenkins building Pharo images for at
least master and development, and potentially big feature branches
before they are merged. The Jenkins also test the images.

Then when I need to work on something, I download the Jenkins archive of
the corresponding branch, double click on the image (some setting are
then loaded) and I'm ready to develop because Jenkins and my settings
have done all the setup.

I try to keep my Jenkins script as simple as possible for the loading.
Ideally I like to have something like this:

./pharo $PROJECT_NAME.image eval --save "
  Metacello new
    baseline: #MaterialDesignLite;
    githubUser: 'DuneSt' project: 'MaterialDesignLite' commitish:
'$VERSION' path: 'src';
    onWarningLog;
    load.
".

With this way to work, I do not really see how locks can help me.
Because I don't want to have to manage possible versions I accept from
all the dependencies in **development**. I want to accept the maximum of
update and when it breaks either I edit the code to work with the new
version of the dependency or I fix the dependency version because it
will be too much work.

Just to explain why I don't want to manage by hand all the dependencies
version in development: I work on a project that at one time had more
than 70 dependencies (transitively).

Now that you know what I understood of the lock feature and that you
know my way to work: Did I miss something on the lock mechanism? Do you
think it can help me during my development? If yes, how would you
include it in my development workflow?

Thank you for the time you spend to help us improve our way to work!

--
Cyril Ferlicot
https://ferlicot.fr

On 03/06/2018 10:51 AM, Cyril Ferlicot D. wrote: Okay, this is how a lock for a ConfigurationOf works, but the effect of
a lock on a BaselineOf is that the FileTree directory where the
BaselineOf is loaded from becomes the "locked version" ... in other
words locking a BaselineOf is really a lock on a git directory and
whatever SHA you happen to have checked out in the location will be used
... and this means that you can explicitily checkout a particular tag in
the git repo and that is the "locked version" For development builds how do you specify/control the version of each of
you 70 dependent projects for your Pharo build ...

The use case for using locks would say that you have 70 cloned git
repositories that you are using for development purposes: i.e, you
anticipate the possibility that you will need to make active changes to
anyone of those 70 cloned git repositories as you do your development
and I assume that you are always operating on the head of the
development branch for each of these 70 cloned repositories ...

Then you would simply lock all 70 projects to the filetree directory for
the projects and when you decide to update to the latest development
branch of a particular project you do a git pull in that clone and your
next build will use the new version of that project ...

When you make a change from within the image and commit a new version in
one of the projects ... again the next build will use the new SHA and so
on ...

Once you've done a lock to a cloned git repo, you don't need to do
fiddle with the BaselineOf, you simply manipulate the version that is
present in the cloned git repo to change which SHA you want to use and
all builds will simple use the "current SHA" for each of projects ...
and since you've got active clones being used, it is simple to commit
from your current working image ...

I know that I've simplified some things here and I still don't see what
you do as an alternative to what I am suggesting with locks ... but
hopefully I've given you a bit clearer picture of what I imagine, you
could/should be doing?

Dale