On 22/06/2015 15:52, Yuriy Tymchuk wrote: +1 nicolas

The point is that I can take my 2 year old Ruby project, load gems and it works. When I take my 2 month old Pharo project that depends on Roassal (this is not only about Roassal, I just have a concrete case) - it breaks. Uko

I am not saying about combining. I want to make my code usable. So when I make something I can say: "Ok, I have a stable version that works on Pharo 4 and depend on Roassal 1.11”. And if someone will want to run it in 2 years, he will download Pharo 4 and run it with Roassal 1.11. Off course it will not work when combined with something that depends on roassal 2.x, but al least it will work alone + other people will know that it’s supposed to work on Roassal 1.11. Uko

On 22-06-15 19:10, Yuriy Tymchuk wrote: Will you update the configuration every time one of your (recursive) dependencies changes? And update the versions of those dependencies too? Otherwise, don't bother. Stephan

On 23-06-15 08:07, Yuriy Tymchuk wrote: #stable There are more people creating broken configurations, mostly using concrete versions. Working with concrete versions in Maven breaks just as much. The Gems approach is what I suggest. In your concrete case that means a dependency on #stable of Roassal2, until Roassal2 starts using releases. I've spend more than two weeks fixing configurations last year. Depending on #stable and #development is bad, but depending on numbered versions is far worse. If you depend on numbered versions, your code won't run. Stephan

On 23-06-15 12:57, Yuriy Tymchuk wrote: 1.11 was created because the Roassal2 configuration assumed Moose as a base, not Pharo. Up to that moment, Roassal2 always specified a dependency on (the latest version of) a package in a repository. A release is something that can be patched, so has a symbolic name. Seaside, Magritte, Grease use releases. That works. 1.11 hardcodes a dependency on GlamourCore 3.1.1. That is the version that was in the original Pharo4 release. The current Pharo4 release has GlamourCore 3.1.5. That hardcodes a dependency on Rubric 1.2.14 instead of the Rubric 1.2.10 at release. #stable for Rubric has moved to 1.2.15 in the mean time. In two year, nobody wants to use the original release of Pharo4 because it has a broken Metacello, and needs to be converted to spur before it will even start. In the latest Pharo4 release your code won't even load. Peter wrote: two months stuff Roassal developers only work on bleeding edge. #stable for Roassal means has been released with a Moose release, or contains a patch for that release. It is a mess because the configurations you depend on (recursively) use numbered versions. That creates duplication of volatile information and should stop. Please note that using #stable here works well because that is a version for Pharo 4, not 5. All Roassal development and new Moose releases happen in 5, so it should be easy to keep #stable stable. For the Moose releases on Pharo 5 we need to add symbolic versions. Stephan

On 23-06-15 14:27, Yuriy Tymchuk wrote: If everyone would correctly use symbolic, the only thing you'd need to do is change your own packages to make it work in the latest version of Pharo 4. That is what we have with Seaside and it works. To make it work with your code, Roassal, Glamour and GT need to switch to symbolic versions too. Stephan

this is why I do not recommend the use of #stable in dependency declarations (I already discussed this in pharo-dev). according to Dale, the better way to handle this would be: - you can use, for example 3.? as dependency, then it will take latest 3 (I never tried this and I’m not sure if it actually works) - you are highly recommended to adopt Seaside convention: they have symbolic versions for #release3, #release3.1, etc. probably a bit more of work, but it works fine. - and of course, you can use a fixed version number (for example: 3.1.1) depending on #stable is #wrong! Esteban

On 23-06-15 15:13, Esteban Lorenzano wrote: +1 Unless your configuration might be used in other configurations. Then you should not depend on a fixed version number. It is not your code, you don't control who fixes bugs in it and the one patching it does not know about you as the dependency is declared in one direction only. Stephan

On Tue, Jun 23, 2015 at 12:26 PM, stephan <stephan(a)stack.nl> wrote: Am I living in different universe? I've been using 1.5(.)2 for over two months because I was tired every time I loaded my project to start by fixing stuff that broke. And depending on #stable _WILL_ break it.

On 23-06-15 15:17, Nicolas Anquetil wrote: That should have been a new symbolic release. And that was clear from the breaking builds on CI. That is where the symbolic versioning of Seaside works rather well. That might work for you because you don't have anyone using your configurations. For configurations that are used by other projects, that results in impossible combinations of version numbers. Depending on symbolic names like #'release3.1' works very well. We get the bug fixes and non-breaking changes. #stable works well for projects that do only bugfixes. Of course it only works as well as the maintainers of the dependencies update their configurations. The PetitParser context change should have been a release. Stephan