Searching for a Roassal2 version
Locked
12
12
 
|
Hi,
I want to depend on a version of Roassal2. Should I depend on 1.11? Because 1.12 and 1.13 have blessing: “broken”. o_O Uko _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
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 > On Jun 22, 2015, at 10:08 AM, Yuriy Tymchuk <[hidden email]> wrote: > > Hi, > > I want to depend on a version of Roassal2. Should I depend on 1.11? Because 1.12 and 1.13 have blessing: “broken”. o_O > > Uko > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Cool, thanks!
Uko > On 22 Jun 2015, at 15:18, Alejandro Infante <[hidden email]> wrote: > > 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 >> On Jun 22, 2015, at 10:08 AM, Yuriy Tymchuk <[hidden email]> wrote: >> >> Hi, >> >> I want to depend on a version of Roassal2. Should I depend on 1.11? Because 1.12 and 1.13 have blessing: “broken”. o_O >> >> Uko >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
In reply to this post by Uko2
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: > Hi, > > I want to depend on a version of Roassal2. Should I depend on 1.11? Because 1.12 and 1.13 have blessing: “broken”. o_O > > Uko > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
What if I don’t want something to change without my knowledge?
Uko > On 22 Jun 2015, at 15:48, stephan <[hidden email]> wrote: > > 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: >> Hi, >> >> I want to depend on a version of Roassal2. Should I depend on 1.11? Because 1.12 and 1.13 have blessing: “broken”. o_O >> >> Uko >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
On 22/06/2015 15:52, Yuriy Tymchuk wrote: > What if I don’t want something to change without my knowledge? +1 nicolas > Uko > >> On 22 Jun 2015, at 15:48, stephan <[hidden email]> wrote: >> >> 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: >>> Hi, >>> >>> I want to depend on a version of Roassal2. Should I depend on 1.11? Because 1.12 and 1.13 have blessing: “broken”. o_O >>> >>> Uko >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
In reply to this post by Stephan Eggermont-3
On Mon, Jun 22, 2015 at 3:48 PM, stephan <[hidden email]> wrote: You should not depend on a numbered version. That is where nearly all our dependency hell Wasn't there a discussion about versioning last week? Dependency hell might make it harder to upgrade (especially if no meaningful system is employed), but depending on #stable is great way to have your project broken at random. Only dead project has stable API. Peter _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
In reply to this post by Uko2
On 22-06-15 15:52, Yuriy Tymchuk wrote:
> What if I don’t want something to change without my knowledge? 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 >Wasn't there a discussion about versioning last week? Yes there was. >Dependency hell might make it harder to upgrade (especially if > no meaningful system is employed), but depending on #stable >is great way to have your project broken at random. Only dead project 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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 > On 22 Jun 2015, at 16:41, stephan <[hidden email]> wrote: > > On 22-06-15 15:52, Yuriy Tymchuk wrote: >> What if I don’t want something to change without my knowledge? > > 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 > >Wasn't there a discussion about versioning last week? > > Yes there was. > > >Dependency hell might make it harder to upgrade (especially if > > no meaningful system is employed), but depending on #stable > >is great way to have your project broken at random. Only dead project 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 > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
On 22-06-15 16:49, Yuriy Tymchuk wrote: > 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. > 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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> On 22 Jun 2015, at 17:45, stephan <[hidden email]> wrote: > > > > On 22-06-15 16:49, Yuriy Tymchuk wrote: >> 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. >> > > 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… 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 > > 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 > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
On Mon, Jun 22, 2015 at 7:10 PM, Yuriy Tymchuk <[hidden email]> 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
-- _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
In reply to this post by Uko2
On 22-06-15 19:10, Yuriy Tymchuk wrote: > 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 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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Sent from my iPhone > On 23 Jun 2015, at 00:39, stephan <[hidden email]> wrote: > > > >> On 22-06-15 19:10, Yuriy Tymchuk wrote: >> 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 > 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 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 > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
On 23-06-15 08:07, Yuriy Tymchuk wrote: > 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. #stable > 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? 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. > Moreover, does everyone really not care to have my projects runable in > the future? Uko If you depend on numbered versions, your code won't run. Stephan _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> On 23 Jun 2015, at 12:26, stephan <[hidden email]> wrote: > > > > On 23-06-15 08:07, Yuriy Tymchuk wrote: >> 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. > > #stable >> 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? > 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. 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 > 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. >> Moreover, does everyone really not care to have my projects runable in the future? Uko > > If you depend on numbered versions, your code won't run. > > Stephan > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
In reply to this post by Stephan Eggermont-3
On Tue, Jun 23, 2015 at 12:26 PM, stephan <[hidden email]> 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. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
In reply to this post by Uko2
On 23-06-15 12:57, Yuriy Tymchuk wrote: > 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> On 23 Jun 2015, at 14:08, stephan <[hidden email]> wrote: > > > > On 23-06-15 12:57, Yuriy Tymchuk wrote: >> 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, 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 > 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: Searching for a Roassal2 version
|
|
On 23-06-15 14:27, 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 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 _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |