Hi, We have a problem with GlamourCore version 3.1.4 and for that reason Roassal2 1.12 and 1.13 can’t be loaded cleanly. We hope this will be solved soon, but if you want to write the ConfigurationOfYourProject today I would recommend depending on 1.11. Alejandro

You should not depend on a numbered version. That is where nearly all our dependency hell problems come from. That currently restricts you to #stable, #development or #bleedingEdge Stephan On 22-06-15 15:08, Yuriy Tymchuk wrote:

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

On 22-06-15 15:52, Yuriy Tymchuk wrote: That is something you cannot afford with current tooling. You can create a snapshot of all package versions, and calculate a md5 over all method versions. You cannot afford to do that for every change but you can do that for important situations. Working software is more important than absolute reproducibility. If you use numbered versions in your dependencies, you break software. In practice. All the time. Because nobody can afford to change versions at the sum rate of all changes of its dependencies. So that doesn't happen. Peter wrote Yes there was. has stable API. That is a separate issue, take a look at the discussion. A dependency needs to be on a symbolic version, and if the API changes in a breaking way that should be reflected there. Stephan

On 22-06-15 16:49, Yuriy Tymchuk wrote: Pharo itself is not yet managed with configurations, and has AFAIK a much higher change rate than Ruby. I have been a lot less lucky with older Ruby stuff, combining stuff from different eras was interesting... That makes it essential not to depend on the numbered versions, as you know that they will need to be patched to keep working on a moving target. Stephan

On Mon, Jun 22, 2015 at 7:10 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: FWIW I always keep a copy of my package-cache around after a full release build. Got bitten more than once with what you experience. Now, I am doing lots of R at the moment and package dependencies aren't a walk in the park either. Phil --

Sent from my iPhone Maybe in next version of my project I will move to Roassal 1.14 if it will not be broken. Or maybe I will stay with 1.11. This discussion is weird. Both in Maven and in Gems I always worked with concrete versions (well, Gems also allow you to depend on all patches or minor versions higher than the specified one, which I found nice). Am I the only one to do that? Moreover, does everyone really not care to have my projects runable in the future? Uko

If 1.11 is not a release then why did someone create that version? I just don’t get this. I know all the problems that happen with dependencies, but I can’t stand when I take someone’s code and it does not work. And this happens not because he/she wrote the code badly, it’s because he/she didn’t say which versions of the other packages were used… And so I have no chance to run it. Nah, I’ll depend on 1.11, so if I need to take a look at my data in a year I’ll be able to do that. I’ve already spent to much time to accommodate to charter/grapher changes although I didn’t benefit from new Roassal versions at all. Uko

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

Maybe it’s not a good approach, but I really enjoy Bundler specs, http://bundler.io/gemfile.html <http://bundler.io/gemfile.html>. They have this notation ~> which allows you to specify, that you want to auto advance parches or minor versions, but not minor or major versions respectively. If X.X. works like this, I really like that. Also if thing’s work like that we don’t need this release symbolics, because 3.1. should work as #release3.1, right? Also is anybody using semantic versioning. Because if you subclass ConfigurationOf, you are forced to use it, and that’s very nice. Uko

I usually try to stay away from fiddling with Configuration. Configurations have the nasty effect to suck all your energy and time. However, I have no problem in adding a particular version if something needs to. Back in the old days, I created a new configuration version for each (even small) code commit. It worked pretty well. But tools broke on some points, and I did not try to redo it. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.