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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Uko2
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

Reply | Threaded
Open this post in threaded view
|

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

EstebanLM

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


Reply | Threaded
Open this post in threaded view
|

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

Uko2
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

Reply | Threaded
Open this post in threaded view
|

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

Stephan Eggermont-3
In reply to this post by EstebanLM
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



Reply | Threaded
Open this post in threaded view
|

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

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