23 Jun
2015
23 Jun
'15
2:27 p.m.
On 23 Jun 2015, at 14:08, stephan
<stephan(a)stack.nl> wrote:
On 23-06-15 12:57, Yuriy Tymchuk wrote:
That’s the point, I’m fine using Pharo 4 in 2 years as long as the projects works. Because
1) I can use it for my reasons 2) I can migrate it if I need to. But if everyone depends
on symbolic, in 2 years I open a project, it doesn’t work because too much changed, I have
no idea what changed, I throw it to trash.
Uko
If 1.11 is not a release then why did someone
create that version?
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.
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
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:
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.
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev