How do you avoid loading master code which is indirectly referenced by a version in the baseline?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How do you avoid loading master code which is indirectly referenced by a version in the baseline?

Sabine Manaa
For test and deployment, I have to be sure that I know exactly which versions
I load and I have to be sure to be able to load exactly the same code again.
I do not speak from my projects but from the projects I use.

I found myself asking people again and again to set tags in their projects
and being surprised again and again by changed code even though I am trying
to load versions (with versions I mean NOT #stable or #master but like
v2.2.2).

The reason for this problem I then have, is that often in baselines with
version numbers (e.g. v2.2.2) other projects are referenced but as master.
So in consequence, I load version but get master from another project which
is referenced indirectly.  

For me, that this is not good at all. I was wondering that this seems not to
be a problem for others.

I found out that I can put a lock in my baselines preLoadDoIt for those
indirectly referenced projects.

Examlpe Artefact v1.0.1

https://github.com/pharo-contributions/Artefact/blob/v1.0.1/src/BaselineOfArtefact/BaselineOfArtefact.class.st

loads github://zweidenker/Units/src (which is master).

I found a solution for this:

In the preLoadDoIt of my baseline I lock Units to a certain commit.

preLoadDoIt
Metacello new
baseline: 'Units';
repository: 'github://zweidenker/Units:98d5a3d/src';
lock.

This solves my problem in this example.

Disadvantage is that I have to analyze everything which is loaded from the
projects I use and create a lock for it.

Questions:
1.) Wouldn't it make sense to have some mechanism, perhaps in Rowan then,
where I can say that a project which has a number can only reference other
projects with numbers? This would avoid the whole problem
2.) How do others solve this problem?

addendum: I do not speak about project versions which are in development,
here #stable or master are great features. But sometime when a project has a
certain state, and it gets a version, then it should not change..imho



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Reply | Threaded
Open this post in threaded view
|

Re: How do you avoid loading master code which is indirectly referenced by a version in the baseline?

Tim Mackinnon
Hi Sabine - you raise an important point, and I am interested in us getting better answers to this too. Hopefully Dale see’s this and is thinking about this in Rowen. Repeatable loading is an important enterprise feature.

Tim

> On 18 Feb 2019, at 15:46, Sabine Manaa <[hidden email]> wrote:
>
> For test and deployment, I have to be sure that I know exactly which versions
> I load and I have to be sure to be able to load exactly the same code again.
> I do not speak from my projects but from the projects I use.
>
> I found myself asking people again and again to set tags in their projects
> and being surprised again and again by changed code even though I am trying
> to load versions (with versions I mean NOT #stable or #master but like
> v2.2.2).
>
> The reason for this problem I then have, is that often in baselines with
> version numbers (e.g. v2.2.2) other projects are referenced but as master.
> So in consequence, I load version but get master from another project which
> is referenced indirectly.  
>
> For me, that this is not good at all. I was wondering that this seems not to
> be a problem for others.
>
> I found out that I can put a lock in my baselines preLoadDoIt for those
> indirectly referenced projects.
>
> Examlpe Artefact v1.0.1
>
> https://github.com/pharo-contributions/Artefact/blob/v1.0.1/src/BaselineOfArtefact/BaselineOfArtefact.class.st
>
> loads github://zweidenker/Units/src (which is master).
>
> I found a solution for this:
>
> In the preLoadDoIt of my baseline I lock Units to a certain commit.
>
> preLoadDoIt
> Metacello new
> baseline: 'Units';
> repository: 'github://zweidenker/Units:98d5a3d/src';
> lock.
>
> This solves my problem in this example.
>
> Disadvantage is that I have to analyze everything which is loaded from the
> projects I use and create a lock for it.
>
> Questions:
> 1.) Wouldn't it make sense to have some mechanism, perhaps in Rowan then,
> where I can say that a project which has a number can only reference other
> projects with numbers? This would avoid the whole problem
> 2.) How do others solve this problem?
>
> addendum: I do not speak about project versions which are in development,
> here #stable or master are great features. But sometime when a project has a
> certain state, and it gets a version, then it should not change..imho
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>


Reply | Threaded
Open this post in threaded view
|

Re: How do you avoid loading master code which is indirectly referenced by a version in the baseline?

philippeback
Same boat here.

Phil

On Tue, Feb 19, 2019, 13:05 Tim Mackinnon <[hidden email] wrote:
Hi Sabine - you raise an important point, and I am interested in us getting better answers to this too. Hopefully Dale see’s this and is thinking about this in Rowen. Repeatable loading is an important enterprise feature.

Tim

> On 18 Feb 2019, at 15:46, Sabine Manaa <[hidden email]> wrote:
>
> For test and deployment, I have to be sure that I know exactly which versions
> I load and I have to be sure to be able to load exactly the same code again.
> I do not speak from my projects but from the projects I use.
>
> I found myself asking people again and again to set tags in their projects
> and being surprised again and again by changed code even though I am trying
> to load versions (with versions I mean NOT #stable or #master but like
> v2.2.2).
>
> The reason for this problem I then have, is that often in baselines with
> version numbers (e.g. v2.2.2) other projects are referenced but as master.
> So in consequence, I load version but get master from another project which
> is referenced indirectly. 
>
> For me, that this is not good at all. I was wondering that this seems not to
> be a problem for others.
>
> I found out that I can put a lock in my baselines preLoadDoIt for those
> indirectly referenced projects.
>
> Examlpe Artefact v1.0.1
>
> https://github.com/pharo-contributions/Artefact/blob/v1.0.1/src/BaselineOfArtefact/BaselineOfArtefact.class.st
>
> loads github://zweidenker/Units/src (which is master).
>
> I found a solution for this:
>
> In the preLoadDoIt of my baseline I lock Units to a certain commit.
>
> preLoadDoIt
> Metacello new
> baseline: 'Units';
> repository: 'github://zweidenker/Units:98d5a3d/src';
> lock.
>
> This solves my problem in this example.
>
> Disadvantage is that I have to analyze everything which is loaded from the
> projects I use and create a lock for it.
>
> Questions:
> 1.) Wouldn't it make sense to have some mechanism, perhaps in Rowan then,
> where I can say that a project which has a number can only reference other
> projects with numbers? This would avoid the whole problem
> 2.) How do others solve this problem?
>
> addendum: I do not speak about project versions which are in development,
> here #stable or master are great features. But sometime when a project has a
> certain state, and it gets a version, then it should not change..imho
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>



Reply | Threaded
Open this post in threaded view
|

Re: How do you avoid loading master code which is indirectly referenced by a version in the baseline?

Guillermo Polito
In reply to this post by Tim Mackinnon
Hi Sabine,

maybe you want to have a look at metacello lock.


On Tue, Feb 19, 2019 at 1:06 PM Tim Mackinnon <[hidden email]> wrote:
Hi Sabine - you raise an important point, and I am interested in us getting better answers to this too. Hopefully Dale see’s this and is thinking about this in Rowen. Repeatable loading is an important enterprise feature.

Tim

> On 18 Feb 2019, at 15:46, Sabine Manaa <[hidden email]> wrote:
>
> For test and deployment, I have to be sure that I know exactly which versions
> I load and I have to be sure to be able to load exactly the same code again.
> I do not speak from my projects but from the projects I use.
>
> I found myself asking people again and again to set tags in their projects
> and being surprised again and again by changed code even though I am trying
> to load versions (with versions I mean NOT #stable or #master but like
> v2.2.2).
>
> The reason for this problem I then have, is that often in baselines with
> version numbers (e.g. v2.2.2) other projects are referenced but as master.
> So in consequence, I load version but get master from another project which
> is referenced indirectly. 
>
> For me, that this is not good at all. I was wondering that this seems not to
> be a problem for others.
>
> I found out that I can put a lock in my baselines preLoadDoIt for those
> indirectly referenced projects.
>
> Examlpe Artefact v1.0.1
>
> https://github.com/pharo-contributions/Artefact/blob/v1.0.1/src/BaselineOfArtefact/BaselineOfArtefact.class.st
>
> loads github://zweidenker/Units/src (which is master).
>
> I found a solution for this:
>
> In the preLoadDoIt of my baseline I lock Units to a certain commit.
>
> preLoadDoIt
> Metacello new
> baseline: 'Units';
> repository: 'github://zweidenker/Units:98d5a3d/src';
> lock.
>
> This solves my problem in this example.
>
> Disadvantage is that I have to analyze everything which is loaded from the
> projects I use and create a lock for it.
>
> Questions:
> 1.) Wouldn't it make sense to have some mechanism, perhaps in Rowan then,
> where I can say that a project which has a number can only reference other
> projects with numbers? This would avoid the whole problem
> 2.) How do others solve this problem?
>
> addendum: I do not speak about project versions which are in development,
> here #stable or master are great features. But sometime when a project has a
> certain state, and it gets a version, then it should not change..imho
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
>




--

   

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


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13