Released versions in Pharo Bootstrap

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

Released versions in Pharo Bootstrap

tesonep@gmail.com
Hello, 
     i have seen in the latest version of Pharo baselines pointing to "floating" versions. A version that is not fixed. I want to know why this is like that? 

To me this is basically wrong, because basically this goes against the idea of having repeatable builds. Also using semantic versions with tags in Git is wrong, as tags should be immutable (that is why you have to use --force to update them, in Guille's words "If you have to force it, it is not good"). 

Cheers,

--
Pablo Tesone.
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Pavel Krivanek-3
Hi,

it is an issue of Calypso dependencies. I discussed it with Denis
before Calypso integration and he would like to change it but, for
now, it would make the development for him much harder because he
needs a way how to load the latest bleeding edge versions of the
packages and no one was able to tell him the proper way how to support
both scenarios (loading of a specific release and loading of the
development versions) with baselines without needing of duplicate
them.

Anyway, I agree that the current state must be fixed as soon as possible.

Cheers,
-- Pavel

2018-03-05 15:30 GMT+01:00 [hidden email] <[hidden email]>:

> Hello,
>      i have seen in the latest version of Pharo baselines pointing to
> "floating" versions. A version that is not fixed. I want to know why this is
> like that?
>
> To me this is basically wrong, because basically this goes against the idea
> of having repeatable builds. Also using semantic versions with tags in Git
> is wrong, as tags should be immutable (that is why you have to use --force
> to update them, in Guille's words "If you have to force it, it is not
> good").
>
> Cheers,
>
> --
> Pablo Tesone.
> [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

tesonep@gmail.com
Yes, I understand for the developer version, you should have a developer branch and use that. The problem is for the Pharo image only. 

On Mon, Mar 5, 2018 at 3:39 PM, Pavel Krivanek <[hidden email]> wrote:
Hi,

it is an issue of Calypso dependencies. I discussed it with Denis
before Calypso integration and he would like to change it but, for
now, it would make the development for him much harder because he
needs a way how to load the latest bleeding edge versions of the
packages and no one was able to tell him the proper way how to support
both scenarios (loading of a specific release and loading of the
development versions) with baselines without needing of duplicate
them.

Anyway, I agree that the current state must be fixed as soon as possible.

Cheers,
-- Pavel

2018-03-05 15:30 GMT+01:00 [hidden email] <[hidden email]>:
> Hello,
>      i have seen in the latest version of Pharo baselines pointing to
> "floating" versions. A version that is not fixed. I want to know why this is
> like that?
>
> To me this is basically wrong, because basically this goes against the idea
> of having repeatable builds. Also using semantic versions with tags in Git
> is wrong, as tags should be immutable (that is why you have to use --force
> to update them, in Guille's words "If you have to force it, it is not
> good").
>
> Cheers,
>
> --
> Pablo Tesone.
> [hidden email]




--
Pablo Tesone.
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Denis Kudriashov
Hi Pablo.

Dev branch approach not really works. Because any merge into master will break master baseline. (notice that baseline is in same repo).
And managing merges by hand all the time is not a solution.




2018-03-05 15:57 GMT+01:00 [hidden email] <[hidden email]>:
Yes, I understand for the developer version, you should have a developer branch and use that. The problem is for the Pharo image only. 

On Mon, Mar 5, 2018 at 3:39 PM, Pavel Krivanek <[hidden email]> wrote:
Hi,

it is an issue of Calypso dependencies. I discussed it with Denis
before Calypso integration and he would like to change it but, for
now, it would make the development for him much harder because he
needs a way how to load the latest bleeding edge versions of the
packages and no one was able to tell him the proper way how to support
both scenarios (loading of a specific release and loading of the
development versions) with baselines without needing of duplicate
them.

Anyway, I agree that the current state must be fixed as soon as possible.

Cheers,
-- Pavel

2018-03-05 15:30 GMT+01:00 [hidden email] <[hidden email]>:
> Hello,
>      i have seen in the latest version of Pharo baselines pointing to
> "floating" versions. A version that is not fixed. I want to know why this is
> like that?
>
> To me this is basically wrong, because basically this goes against the idea
> of having repeatable builds. Also using semantic versions with tags in Git
> is wrong, as tags should be immutable (that is why you have to use --force
> to update them, in Guille's words "If you have to force it, it is not
> good").
>
> Cheers,
>
> --
> Pablo Tesone.
> [hidden email]




--
Pablo Tesone.
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

CyrilFerlicot
On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <[hidden email]> wrote:
> Hi Pablo.
>
> Dev branch approach not really works. Because any merge into master will
> break master baseline. (notice that baseline is in same repo).
> And managing merges by hand all the time is not a solution.
>
>
Hi!
If you don't want to manage the merges by hand you can maybe have two bsaelines?
BaselineOfCalypso and BaselineOfCalypsoDev?

--
Cyril Ferlicot
https://ferlicot.fr

Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Denis Kudriashov
In reply to this post by tesonep@gmail.com
Also it is not really development versions.
I follow semantics versioning. So I reference 0.3.x versions to get all minor fixes from dependencies. 
 


2018-03-05 15:57 GMT+01:00 [hidden email] <[hidden email]>:
Yes, I understand for the developer version, you should have a developer branch and use that. The problem is for the Pharo image only. 

On Mon, Mar 5, 2018 at 3:39 PM, Pavel Krivanek <[hidden email]> wrote:
Hi,

it is an issue of Calypso dependencies. I discussed it with Denis
before Calypso integration and he would like to change it but, for
now, it would make the development for him much harder because he
needs a way how to load the latest bleeding edge versions of the
packages and no one was able to tell him the proper way how to support
both scenarios (loading of a specific release and loading of the
development versions) with baselines without needing of duplicate
them.

Anyway, I agree that the current state must be fixed as soon as possible.

Cheers,
-- Pavel

2018-03-05 15:30 GMT+01:00 [hidden email] <[hidden email]>:
> Hello,
>      i have seen in the latest version of Pharo baselines pointing to
> "floating" versions. A version that is not fixed. I want to know why this is
> like that?
>
> To me this is basically wrong, because basically this goes against the idea
> of having repeatable builds. Also using semantic versions with tags in Git
> is wrong, as tags should be immutable (that is why you have to use --force
> to update them, in Guille's words "If you have to force it, it is not
> good").
>
> Cheers,
>
> --
> Pablo Tesone.
> [hidden email]




--
Pablo Tesone.
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Denis Kudriashov
In reply to this post by CyrilFerlicot
2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <[hidden email]>:
On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <[hidden email]> wrote:
> Hi Pablo.
>
> Dev branch approach not really works. Because any merge into master will
> break master baseline. (notice that baseline is in same repo).
> And managing merges by hand all the time is not a solution.
>
>
Hi!
If you don't want to manage the merges by hand you can maybe have two bsaelines?
BaselineOfCalypso and BaselineOfCalypsoDev?

It should work. But is it right way that everybody should follow?

With configurations it was easy to do in single class.  
 

--
Cyril Ferlicot
https://ferlicot.fr


Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Guillermo Polito
But, "one single class" does not mean anything. Because it depends from which branch/commitish you are loading it from...

Can you explain better what is the problem because I am not getting it...

In any case, independently of where is the burden, I want to veto any new integration that may make future builds non-reproducible. Otherwise this is a source of chaos and dead kittens.

On Mon, Mar 5, 2018 at 4:17 PM, Denis Kudriashov <[hidden email]> wrote:
2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <[hidden email]>:
On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <[hidden email]> wrote:
> Hi Pablo.
>
> Dev branch approach not really works. Because any merge into master will
> break master baseline. (notice that baseline is in same repo).
> And managing merges by hand all the time is not a solution.
>
>
Hi!
If you don't want to manage the merges by hand you can maybe have two bsaelines?
BaselineOfCalypso and BaselineOfCalypsoDev?

It should work. But is it right way that everybody should follow?

With configurations it was easy to do in single class.  
 

--
Cyril Ferlicot
https://ferlicot.fr





--

   

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

Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Denis Kudriashov
In Configuration I defined two baselines: dev and stable.
In dev baseline I referenced dev version of dependencies.
In stable I referenced stable version of dependencies.

2018-03-05 16:38 GMT+01:00 Guillermo Polito <[hidden email]>:
But, "one single class" does not mean anything. Because it depends from which branch/commitish you are loading it from...

Can you explain better what is the problem because I am not getting it...

In any case, independently of where is the burden, I want to veto any new integration that may make future builds non-reproducible. Otherwise this is a source of chaos and dead kittens.

On Mon, Mar 5, 2018 at 4:17 PM, Denis Kudriashov <[hidden email]> wrote:
2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <[hidden email]>:
On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <[hidden email]> wrote:
> Hi Pablo.
>
> Dev branch approach not really works. Because any merge into master will
> break master baseline. (notice that baseline is in same repo).
> And managing merges by hand all the time is not a solution.
>
>
Hi!
If you don't want to manage the merges by hand you can maybe have two bsaelines?
BaselineOfCalypso and BaselineOfCalypsoDev?

It should work. But is it right way that everybody should follow?

With configurations it was easy to do in single class.  
 

--
Cyril Ferlicot
https://ferlicot.fr





--

   

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: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13


Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

CyrilFerlicot
In reply to this post by Guillermo Polito

On Mon, Mar 5, 2018 at 4:38 PM, Guillermo Polito <[hidden email]> wrote:
But, "one single class" does not mean anything. Because it depends from which branch/commitish you are loading it from...

Can you explain better what is the problem because I am not getting it...

In any case, independently of where is the burden, I want to veto any new integration that may make future builds non-reproducible. Otherwise this is a source of chaos and dead kittens.

The problem is that actually if you have a git project with a stable and dev branch you will need:
- One baseline on the stable branch with determined dependencies versions
- One baseline on the dev branch with less restricted versions (for example 3.x.x)
Then, when you release a new stable version by merging the development branch you need to edit the merge by hand to merge everything except the baseline.
I think this is what Denis wants to avoid. 
But in general, such merges need to be done only for major and minor releases. Not for a patch because you can do a hotfix. You create a new branch from master, then merge in in master and development when it's done. 

--
Cyril Ferlicot
https://ferlicot.fr
Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Guillermo Polito


On Mon, Mar 5, 2018 at 4:45 PM, Cyril Ferlicot <[hidden email]> wrote:

On Mon, Mar 5, 2018 at 4:38 PM, Guillermo Polito <[hidden email]> wrote:
But, "one single class" does not mean anything. Because it depends from which branch/commitish you are loading it from...

Can you explain better what is the problem because I am not getting it...

In any case, independently of where is the burden, I want to veto any new integration that may make future builds non-reproducible. Otherwise this is a source of chaos and dead kittens.

The problem is that actually if you have a git project with a stable and dev branch you will need:
- One baseline on the stable branch with determined dependencies versions
- One baseline on the dev branch with less restricted versions (for example 3.x.x)
Then, when you release a new stable version by merging the development branch you need to edit the merge by hand to merge everything except the baseline.
I think this is what Denis wants to avoid. 
But in general, such merges need to be done only for major and minor releases. Not for a patch because you can do a hotfix. You create a new branch from master, then merge in in master and development when it's done. 

I still do not understand... Also I do not understand your usage of the term "the merge". Can somebody give a **concrete** scenario? 

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



--

   

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

Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Denis Kudriashov
In reply to this post by Guillermo Polito
Maybe we should just load Calypso dependencies explicitly.
In any case they will be used by other projects. Like new Iceberg will use Commander. And ClassAnnotation will be in Kernel.
So we will need to load them in another time than Calypso.

Now we can just put them directly into #loadCalypso method. (there are three dependencies)
It will fix my problem and make Pharo build reproducible.

2018-03-05 16:38 GMT+01:00 Guillermo Polito <[hidden email]>:
But, "one single class" does not mean anything. Because it depends from which branch/commitish you are loading it from...

Can you explain better what is the problem because I am not getting it...

In any case, independently of where is the burden, I want to veto any new integration that may make future builds non-reproducible. Otherwise this is a source of chaos and dead kittens.

On Mon, Mar 5, 2018 at 4:17 PM, Denis Kudriashov <[hidden email]> wrote:
2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <[hidden email]>:
On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <[hidden email]> wrote:
> Hi Pablo.
>
> Dev branch approach not really works. Because any merge into master will
> break master baseline. (notice that baseline is in same repo).
> And managing merges by hand all the time is not a solution.
>
>
Hi!
If you don't want to manage the merges by hand you can maybe have two bsaelines?
BaselineOfCalypso and BaselineOfCalypsoDev?

It should work. But is it right way that everybody should follow?

With configurations it was easy to do in single class.  
 

--
Cyril Ferlicot
https://ferlicot.fr





--

   

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: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13


Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Guillermo Polito
But can you explain me the scenario? I still don't understand it :(

On Mon, Mar 5, 2018 at 4:51 PM, Denis Kudriashov <[hidden email]> wrote:
Maybe we should just load Calypso dependencies explicitly.
In any case they will be used by other projects. Like new Iceberg will use Commander. And ClassAnnotation will be in Kernel.
So we will need to load them in another time than Calypso.

Now we can just put them directly into #loadCalypso method. (there are three dependencies)
It will fix my problem and make Pharo build reproducible.

2018-03-05 16:38 GMT+01:00 Guillermo Polito <[hidden email]>:
But, "one single class" does not mean anything. Because it depends from which branch/commitish you are loading it from...

Can you explain better what is the problem because I am not getting it...

In any case, independently of where is the burden, I want to veto any new integration that may make future builds non-reproducible. Otherwise this is a source of chaos and dead kittens.

On Mon, Mar 5, 2018 at 4:17 PM, Denis Kudriashov <[hidden email]> wrote:
2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <[hidden email]>:
On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <[hidden email]> wrote:
> Hi Pablo.
>
> Dev branch approach not really works. Because any merge into master will
> break master baseline. (notice that baseline is in same repo).
> And managing merges by hand all the time is not a solution.
>
>
Hi!
If you don't want to manage the merges by hand you can maybe have two bsaelines?
BaselineOfCalypso and BaselineOfCalypsoDev?

It should work. But is it right way that everybody should follow?

With configurations it was easy to do in single class.  
 

--
Cyril Ferlicot
https://ferlicot.fr





--

   

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: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13





--

   

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

Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

CyrilFerlicot
In reply to this post by Guillermo Polito

On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Pavel Krivanek-3
In reply to this post by Guillermo Polito
as far as I understand it, you have this:

Calypso v1
 - Commander v1
    - ClassAnnotations v1

You are working on and you fix a version in ClassAnnotations

Calypso v1
 - Commander v1
    - ClassAnnotations v2

but you still do not want to make it as a release. When rebuilding your image, you want to be able to load all three packages in the latest state. Then you make a new change in Calypso

Calypso v2
 - Commander v1
    - ClassAnnotations v2

and you want to mark this dependency tree as a new release version

-- Pavel


2018-03-05 16:57 GMT+01:00 Guillermo Polito <[hidden email]>:
But can you explain me the scenario? I still don't understand it :(

On Mon, Mar 5, 2018 at 4:51 PM, Denis Kudriashov <[hidden email]> wrote:
Maybe we should just load Calypso dependencies explicitly.
In any case they will be used by other projects. Like new Iceberg will use Commander. And ClassAnnotation will be in Kernel.
So we will need to load them in another time than Calypso.

Now we can just put them directly into #loadCalypso method. (there are three dependencies)
It will fix my problem and make Pharo build reproducible.

2018-03-05 16:38 GMT+01:00 Guillermo Polito <[hidden email]>:
But, "one single class" does not mean anything. Because it depends from which branch/commitish you are loading it from...

Can you explain better what is the problem because I am not getting it...

In any case, independently of where is the burden, I want to veto any new integration that may make future builds non-reproducible. Otherwise this is a source of chaos and dead kittens.

On Mon, Mar 5, 2018 at 4:17 PM, Denis Kudriashov <[hidden email]> wrote:
2018-03-05 16:13 GMT+01:00 Cyril Ferlicot <[hidden email]>:
On Mon, Mar 5, 2018 at 4:10 PM, Denis Kudriashov <[hidden email]> wrote:
> Hi Pablo.
>
> Dev branch approach not really works. Because any merge into master will
> break master baseline. (notice that baseline is in same repo).
> And managing merges by hand all the time is not a solution.
>
>
Hi!
If you don't want to manage the merges by hand you can maybe have two bsaelines?
BaselineOfCalypso and BaselineOfCalypsoDev?

It should work. But is it right way that everybody should follow?

With configurations it was easy to do in single class.  
 

--
Cyril Ferlicot
https://ferlicot.fr





--

   

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: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13





--

   

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: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13


Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Denis Kudriashov
In reply to this post by CyrilFerlicot
2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <[hidden email]>:

On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito <[hidden email]> 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".

I do not agree with this sentence: 
 
Since it's stable, BaselineOfMaterialDesignLite should depend only on fixed version of the dependencies. For example it should depend on MaterialDesignColor "v1.0.0".

Maybe I am wrong of course. But this is what I expect from semantic versioning:

If I made project which uses some libraries I want to get latest fixes even in my stable version. This is what semantics versioning is about. Minor releases are supposed to be safe for dependent projects.
It is of course question of trust to third parties. But if I do not trust them I should fork dependency and use it instead of original one.

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

Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Stephan Eggermont-3
In reply to this post by tesonep@gmail.com
[hidden email]
<[hidden email]> wrote:
> Hello,
>      i have seen in the latest version of Pharo baselines pointing to
> "floating" versions. A version that is not fixed. I want to know why this
> is like that?

Because that is the way it should be? It is hand-edited, so repeatable
builds are not the goal, just working software. Repeatable builds come from
recording what you loaded in what order. Repeatable builds with fixed
dependency versions don't help you with working software, as they block
your dependencies from getting patched. Never depend on hard-coded versions
of anything you don't control yourself. See the 5D paper

Stephan Eggermont



Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Nicolas Cellier
In reply to this post by Denis Kudriashov
The well known problem with fixed configurations is dependencies:

My project A version 1.2.3 depends on project C version 4.3 (semantic versioning). I have tested it with 4.3.35, it works well...
If semantic versioning is correctly used, it should work with any 4.x.y where x>=3.
There is another project B version 2.1.4 which depends on project C version 4.4 (still semantic).

Loading latest patch 4.4.20 should work for both A & B.
And even 4.6.11 which is the latest compatible version in 4.x serie

IMO, the package ConfigurationOfPackageA and ConfigurationOfPackageB should NOT specify the exact version of package C, but only the minimal compatible version.
Then, if you want a reproducible image, that is up to the specific assembly of package A and package B (let's call it ConfigurationOfPackageAandBandC) that you should force the specific C version.

Isn't it the problem?

2018-03-05 17:17 GMT+01:00 Denis Kudriashov <[hidden email]>:
2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <[hidden email]>:

On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito <[hidden email]> 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".

I do not agree with this sentence: 
 
Since it's stable, BaselineOfMaterialDesignLite should depend only on fixed version of the dependencies. For example it should depend on MaterialDesignColor "v1.0.0".

Maybe I am wrong of course. But this is what I expect from semantic versioning:

If I made project which uses some libraries I want to get latest fixes even in my stable version. This is what semantics versioning is about. Minor releases are supposed to be safe for dependent projects.
It is of course question of trust to third parties. But if I do not trust them I should fork dependency and use it instead of original one.

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


Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Guillermo Polito
Yes and no. I think I kind of get it now from all comments... There are two problems together, one is how to reproduce the loading of a project (or getting a working version), and the other is how to use metacello also to manage the development of the project when the dependencies feel more like subprojects that may be edited altogether...

On one side there is the reproducibility problem. I understand Stephan's and Nicolas' points. Using exact versions may block development. However, I see also that people in general have problems using semantic versioning and getting working versions done. This morning the image was broken because of wrong but "not fixed" dependencies... This afternoon Pablo was blocked executing the bootstrap because iceberg's and the image version did not match and Metacello was not the best friend when resolving a conflict on a package that did not exist on one of the two conflicting versions...

So yes, it may block upgrades, but until we have tools that allow us to cope with the complexity, I prefer to have reproducible versions where I can reproduce bugs in a reproducible way than an unpredictable version where I cannot grasp the cause of a problem :/.

On the other side, there is the fact that Metacello baselines are so far nice to describe release project dependencies, but they are not so nice to describe subprojects/development dependencies that may get edited along with the parent project. Kind of what we used to do with #bleedingEdge. I feel this is a complex problem, that not even SBT or maven that are there since years are capable of solving nicely... Tode and Iceberg metacello integration try to solve this problem by "ignoring the dependency and using the loaded repository" but this may not be successful either...

Now, pushing the complexity to how we manage the Pharo repository is not the solution either :)

On Mon, Mar 5, 2018 at 5:51 PM, Nicolas Cellier <[hidden email]> wrote:
The well known problem with fixed configurations is dependencies:

My project A version 1.2.3 depends on project C version 4.3 (semantic versioning). I have tested it with 4.3.35, it works well...
If semantic versioning is correctly used, it should work with any 4.x.y where x>=3.
There is another project B version 2.1.4 which depends on project C version 4.4 (still semantic).

Loading latest patch 4.4.20 should work for both A & B.
And even 4.6.11 which is the latest compatible version in 4.x serie

IMO, the package ConfigurationOfPackageA and ConfigurationOfPackageB should NOT specify the exact version of package C, but only the minimal compatible version.
Then, if you want a reproducible image, that is up to the specific assembly of package A and package B (let's call it ConfigurationOfPackageAandBandC) that you should force the specific C version.

Isn't it the problem?

2018-03-05 17:17 GMT+01:00 Denis Kudriashov <[hidden email]>:
2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <[hidden email]>:

On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito <[hidden email]> 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".

I do not agree with this sentence: 
 
Since it's stable, BaselineOfMaterialDesignLite should depend only on fixed version of the dependencies. For example it should depend on MaterialDesignColor "v1.0.0".

Maybe I am wrong of course. But this is what I expect from semantic versioning:

If I made project which uses some libraries I want to get latest fixes even in my stable version. This is what semantics versioning is about. Minor releases are supposed to be safe for dependent projects.
It is of course question of trust to third parties. But if I do not trust them I should fork dependency and use it instead of original one.

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





--

   

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

Reply | Threaded
Open this post in threaded view
|

Re: Released versions in Pharo Bootstrap

Stephane Ducasse-3


On Mon, Mar 5, 2018 at 6:07 PM, Guillermo Polito <[hidden email]> wrote:
Yes and no. I think I kind of get it now from all comments... There are two problems together, one is how to reproduce the loading of a project (or getting a working version), and the other is how to use metacello also to manage the development of the project when the dependencies feel more like subprojects that may be edited altogether...

On one side there is the reproducibility problem. I understand Stephan's and Nicolas' points. Using exact versions may block development. However, I see also that people in general have problems using semantic versioning and getting working versions done. This morning the image was broken because of wrong but "not fixed" dependencies... This afternoon Pablo was blocked executing the bootstrap because iceberg's and the image version did not match and Metacello was not the best friend when resolving a conflict on a package that did not exist on one of the two conflicting versions...

So yes, it may block upgrades, but until we have tools that allow us to cope with the complexity, I prefer to have reproducible versions where I can reproduce bugs in a reproducible way than an unpredictable version where I cannot grasp the cause of a problem :/.

I understand the point of not hardcoding version but for the bootstrap I think at reproducibility is key. 

On the other side, there is the fact that Metacello baselines are so far nice to describe release project dependencies, but they are not so nice to describe subprojects/development dependencies that may get edited along with the parent project. Kind of what we used to do with #bleedingEdge. I feel this is a complex problem, that not even SBT or maven

what is SBT and 
how maven solves it?

 
that are there since years are capable of solving nicely... Tode and Iceberg metacello integration try to solve this problem by "ignoring the dependency and using the loaded repository" but this may not be successful either...

Now, pushing the complexity to how we manage the Pharo repository is not the solution either :)

On Mon, Mar 5, 2018 at 5:51 PM, Nicolas Cellier <[hidden email]> wrote:
The well known problem with fixed configurations is dependencies:

My project A version 1.2.3 depends on project C version 4.3 (semantic versioning). I have tested it with 4.3.35, it works well...
If semantic versioning is correctly used, it should work with any 4.x.y where x>=3.
There is another project B version 2.1.4 which depends on project C version 4.4 (still semantic).

Loading latest patch 4.4.20 should work for both A & B.
And even 4.6.11 which is the latest compatible version in 4.x serie

IMO, the package ConfigurationOfPackageA and ConfigurationOfPackageB should NOT specify the exact version of package C, but only the minimal compatible version.
Then, if you want a reproducible image, that is up to the specific assembly of package A and package B (let's call it ConfigurationOfPackageAandBandC) that you should force the specific C version.

Isn't it the problem?

2018-03-05 17:17 GMT+01:00 Denis Kudriashov <[hidden email]>:
2018-03-05 17:02 GMT+01:00 Cyril Ferlicot <[hidden email]>:

On Mon, Mar 5, 2018 at 4:51 PM, Guillermo Polito <[hidden email]> 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".

I do not agree with this sentence: 
 
Since it's stable, BaselineOfMaterialDesignLite should depend only on fixed version of the dependencies. For example it should depend on MaterialDesignColor "v1.0.0".

Maybe I am wrong of course. But this is what I expect from semantic versioning:

If I made project which uses some libraries I want to get latest fixes even in my stable version. This is what semantics versioning is about. Minor releases are supposed to be safe for dependent projects.
It is of course question of trust to third parties. But if I do not trust them I should fork dependency and use it instead of original one.

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





--

   

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: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13


123