Smalltalk › Frameworks & Tools › Moose

Searching for a Roassal2 version

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

29 messages Options

Uko2

Re: Searching for a Roassal2 version

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

In short: we are arguing on depending on numbered versions vs symbolic.

Uko

On 23 Jun 2015, at 14:40, stephan <[hidden email]> 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
[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

EstebanLM

Re: [Pharo-dev] Re: Searching for a Roassal2 version

On 23 Jun 2015, at 15:00, Yuriy Tymchuk <[hidden email]> 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

In short: we are arguing on depending on numbered versions vs symbolic.

Uko

On 23 Jun 2015, at 14:40, stephan <[hidden email]> 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
[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

Nicolas Anquetil

Re: Searching for a Roassal2 version

In reply to this post by Peter Uhnak

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 <[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

Uko2

Re: [Pharo-dev] Re: Searching for a Roassal2 version

In reply to this post by EstebanLM

Maybe it’s not a good approach, but I really enjoy Bundler specs, 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 <[hidden email]> wrote:

On 23 Jun 2015, at 15:00, Yuriy Tymchuk <[hidden email]> 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

In short: we are arguing on depending on numbered versions vs symbolic.

Uko

On 23 Jun 2015, at 14:40, stephan <[hidden email]> 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
[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

Stephan Eggermont-3

Re: Searching for a Roassal2 version

In reply to this post by Nicolas Anquetil

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

abergel

Re: Searching for a Roassal2 version

In reply to this post by Stephan Eggermont-3

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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

On Jun 23, 2015, at 9:08 AM, stephan <[hidden email]> wrote:

It is a mess because the configurations you depend on (recursively)
use numbered versions. That creates duplication of volatile information
and should stop.

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stephan Eggermont-3

Re: [Pharo-dev] Re: Searching for a Roassal2 version

In reply to this post by EstebanLM

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.

- 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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Uko2

Re: [Pharo-dev] Re: Searching for a Roassal2 version

In reply to this post by EstebanLM

IMHO project’s version should be orthogonal to pharo versions as much as possible.

Uko

> On 23 Jun 2015, at 15:49, Stephan Eggermont <[hidden email]> wrote:
>
> On 23-06-15 15:13, Esteban Lorenzano wrote:
>
>> depending on #stable is #wrong!
>
> The one situation where depending on #stable is ok is
> where we talk about a Pharo 4 version where
> new development is only on Pharo 5. Stable is then
> only a moving target on Pharo 5, not on 4.
>
> Stephan
>
>
>

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Stephan Eggermont-3

Re: [Pharo-dev] Re: Searching for a Roassal2 version

On 23-06-15 16:03, Yuriy Tymchuk wrote:
> IMHO project’s version should be orthogonal to pharo versions as much as possible.
>
Preferably yes. Using symbolic dependencies helps a lot with that.

Stephan
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev