We've been bitten a few times at Ta Mère by the problem of changing metacello configuration. Has anyone already tempted to centralize configurations/package in a read-only place (S3? Azure Storage?). Something like RubyGems or similar. It may be completely stupid to have centralised system but I'm not satisfied with the infastructure supporting our configurations.At the moment, we rely on the policy of "you should never change a Metacello version once it has been published". Of course this is fragile and we've ended up with different code loaded in different environment while we were expecting stuff to be identical. |
Salut Francois
> We've been bitten a few times at Ta Mère by the problem of changing > metacello configuration. I agree. This is why I also think that released should point to version and not symbolic version. What I do is that we can use versionner to release more often configurations pointing to the versions. Christophe will continue to improve it. > At the moment, we rely on the policy of "you should never change a > Metacello version once it has been published". Of course this is > fragile and we've ended up with different code loaded in different > environment while we were expecting stuff to be identical. > > Has anyone already tempted to centralize configurations/package in a > read-only place (S3? Azure Storage?). Something like RubyGems or > similar. It may be completely stupid to have centralised system but > I'm not satisfied with the infastructure supporting our configurations. > > Am I the only one having this problem? How do you handle it? - I was thinking that each project/package should have its own configuration saved in his repo. -- then the developer may choose to publish it to a central place. - other are telling to me that other language have a central place. This is ok too. I would like to have a catalog of frozen versions per pharo version. Now this is two years that we request an engineering to build a project validator and a catalog but we failed. Stef |
In reply to this post by fstephany
Hi François
It sounds like you need snapshots. That has nothing to do with Metacello. Stephan |
In reply to this post by fstephany
Stef wrote
>I agree. This is why I also think that released should point to version >and not symbolic version. I strongly disagree. A configuration should only change when there is a meaningful change. Changes in dependencies that do not change relevant behavior should not propagate. We achieve that by using #'releasex.x' style versioning. Changes that are not supposed to change observable behavior and bug fixes get new numbered versions within the release. #development versions are updated in place. In Moose we did not encounter a situation where a month-old numbered version configuration was still loadable in the latest Pharo. There is a use case for snapshots of exact versions. They don't belong in configurations. Focussing improvements in Versioner on releasing more often numbered versions is counter productive. It just generates more work to keep configurations working. I have been fixing lots of configurations on ci, and nearly all problems have to do with not using #'releasex.x' style symbolic versioning. There are two problems: - Configurations using numbered versions. They break as soon as a dependent project changes functionality or does a bug fix, often as a result of underlying code in Pharo changing. - Configurations using #stable, where the dependent project does a new release. Now Seaside, Grease and Magritte have switched to this style of versioning, the number of problems has reduced drastically. Stephan |
We will discuss that on a black board at ESUG.
A release is a release and when you release code you do not want to rely on something that somewhere could change. Christophe told me that they are doing that in Java world and this is working. Now for development you load your baseline and you load symbolic version of foreign code. Stef >> I agree. This is why I also think that released should point to version >> and not symbolic version. > I strongly disagree. A configuration should only change when > there is a meaningful change. Changes in dependencies that do not > change relevant behavior should not propagate. > > We achieve that by using #'releasex.x' style versioning. Changes that > are not supposed to change observable behavior and bug fixes get > new numbered versions within the release. > #development versions are updated in place > > In Moose we did not encounter a situation where a month-old numbered > version configuration was still loadable in the latest Pharo. ??? > > There is a use case for snapshots of exact versions. They don't belong > in configurations. I do not get what you mean. Now if I want to deliver exactly the same version I do not see how we can avoid versions. And this "nothing observable changes" is a nice idea but what I see is that often pharo breaks because of a nothing observable change. > > Focussing improvements in Versioner on releasing more often numbered > versions is counter productive. It just generates more work to keep > configurations working. I do not think so - in dev you use baseline for you and development for foreign code - when releasing you freeze. With nice tool support I do not see why this would not work. > > I have been fixing lots of configurations on ci, and nearly all problems > have to do with not using #'releasex.x' style symbolic versioning. I did not get it so you should explain it better :) > There are two problems: > - Configurations using numbered versions. They break as soon as a > dependent project changes functionality or does a bug fix, often as > a result of underlying code in Pharo changing. > - Configurations using #stable, where the dependent project does > a new release. Most of the projects on Jenkins are not there to work against release but day to day changes in this case they should load latest. > > Now Seaside, Grease and Magritte have switched to this style of > versioning, the number of problems has reduced drastically. > > Stephan > > > > |
In reply to this post by Stephan Eggermont-3
BTW an important point.
We cannot load any moose versions of the past (except the ones we snapshotted), to me this is a sign of problems. never be able to get back in a previous state is a problem. Stef |
In reply to this post by fstephany
I'll be in Lille tomorrow. We could have a beer instead of a blackboard ;)
Stephan |
Free forum by Nabble | Edit this page |