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
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 yuriy.tymchuk@me.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Cool, thanks!
Uko
On 22 Jun 2015, at 15:18, Alejandro Infante alejandroinfante91@gmail.com 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 yuriy.tymchuk@me.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 Moose-dev@iam.unibe.ch 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 stephan@stack.nl 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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 stephan@stack.nl 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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 stephan@stack.nl 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
On 22 Jun 2015, at 17:45, stephan stephan@stack.nl 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Mon, Jun 22, 2015 at 7:10 PM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
On 22 Jun 2015, at 17:45, stephan stephan@stack.nl 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.
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
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
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
Sent from my iPhone
On 23 Jun 2015, at 00:39, stephan stephan@stack.nl 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
On 23 Jun 2015, at 12:26, stephan stephan@stack.nl 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
On 23 Jun 2015, at 14:08, stephan stephan@stack.nl 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
I don’t get this. I do a project and I have version 4.3. Then I make a major changes i.e. change API without backwards compatibility and create version 5.0. Now 5.0 is stable, but if someone depends on my package’s stable version, he has to rewrite his code, otherwise his package is insta-broken.
I think this has to be also discussed with Pharo developers, who missed the main conversation, here it is: http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html
In short: we are arguing on depending on numbered versions vs symbolic.
Uko
On 23 Jun 2015, at 14:40, stephan stephan@stack.nl wrote:
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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 23 Jun 2015, at 15:00, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:
I don’t get this. I do a project and I have version 4.3. Then I make a major changes i.e. change API without backwards compatibility and create version 5.0. Now 5.0 is stable, but if someone depends on my package’s stable version, he has to rewrite his code, otherwise his package is insta-broken.
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
I think this has to be also discussed with Pharo developers, who missed the main conversation, here it is: http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html
In short: we are arguing on depending on numbered versions vs symbolic.
Uko
On 23 Jun 2015, at 14:40, stephan <stephan@stack.nl mailto:stephan@stack.nl> wrote:
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 Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
On 23 Jun 2015, at 15:13, Esteban Lorenzano estebanlm@gmail.com wrote:
On 23 Jun 2015, at 15:00, Yuriy Tymchuk <yuriy.tymchuk@me.com mailto:yuriy.tymchuk@me.com> wrote:
I don’t get this. I do a project and I have version 4.3. Then I make a major changes i.e. change API without backwards compatibility and create version 5.0. Now 5.0 is stable, but if someone depends on my package’s stable version, he has to rewrite his code, otherwise his package is insta-broken.
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
I think this has to be also discussed with Pharo developers, who missed the main conversation, here it is: http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html http://forum.world.st/Searching-for-a-Roassal2-version-td4833461.html
In short: we are arguing on depending on numbered versions vs symbolic.
Uko
On 23 Jun 2015, at 14:40, stephan <stephan@stack.nl mailto:stephan@stack.nl> wrote:
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 Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch mailto:Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On 23-06-15 15:13, Esteban Lorenzano wrote:
- 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.
+1
- and of course, you can use a fixed version number (for example: 3.1.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
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
On Tue, Jun 23, 2015 at 12:26 PM, stephan stephan@stack.nl 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. 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.
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.
Same here,
we walked in the office one day and our system was broken because of some change in petitParser. The same thing happenned with roassal and other libraries. We are not always (rarely) in a position where we can fix our code to keep working with the new version of the libraries we use.
This does not mean the developers are not good, it is just that they evolve their stuff according to their needs and our needs are not the same.
So our solution is to rely on static revision numbers that are known to work. From time to time, when we are ready, we do the work to update to a new version of the libraries.
This saves us a lot of time and even more troubles.
Depending on symbolic names like "stable" is no good because the stable revision also moves, and not always when we are ready for it.
This is not true for everything, moose for example tends to be much more stable that Roassal which evolves at a fast pace. PetitParser evolves more slowly too, but for a long time, there has been a change in it which we could not leave with (not sure what is the status currently)
So we try to keep with the latest version when we can, but sometimes it is not a viable solution
nicolas
On 23/06/2015 13:35, Peter Uhnák wrote:
On Tue, Jun 23, 2015 at 12:26 PM, stephan <stephan@stack.nl mailto:stephan@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:
we walked in the office one day and our system was broken because of some change in petitParser.
That should have been a new symbolic release. And that was clear from the breaking builds on CI.
The same thing happenned with roassal and other libraries. We are not always (rarely) in a position where we can fix our code to keep working with the new version of the libraries we use.
That is where the symbolic versioning of Seaside works rather well.
This does not mean the developers are not good, it is just that they evolve their stuff according to their needs and our needs are not the same.
So our solution is to rely on static revision numbers that are known to work. From time to time, when we are ready, we do the work to update to a new version of the libraries.
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.
This saves us a lot of time and even more troubles.
Depending on symbolic names like "stable" is no good because the stable revision also moves, and not always when we are ready for it.
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.
This is not true for everything, moose for example tends to be much more stable that Roassal which evolves at a fast pace. PetitParser evolves more slowly too, but for a long time, there has been a change in it which we could not leave with (not sure what is the status currently)
The PetitParser context change should have been a release.
Stephan
On Mon, Jun 22, 2015 at 3:48 PM, stephan stephan@stack.nl 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
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
-
Alejandro Infante -
Alexandre Bergel -
Esteban Lorenzano -
Nicolas Anquetil -
Peter Uhnák -
phil＠highoctane.be -
stephan -
Yuriy Tymchuk