Smalltalk › Pharo › Pharo Smalltalk Developers

A thought about backporting

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

20 messages Options

Noury Bouraqadi-2

A thought about backporting

Hi,

Here is a thought I want to share with you.
Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system.

I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer?
There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one).

Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough.
Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version.

Noury
Ecole des Mines de Douai
http://car.mines-douai.fr/noury
--

Torsten Bergmann

Re: A thought about backporting

If a backport happens it can mean two things to a user:

POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...)
NEGATIV: a possible broken API introduced by a backport

It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip"
from http://files.pharo.org/platform directly after the "big announcement" and half year
later (after backports happened) he may be surprised since it results in different images
and may lead to problems. Not directly in the image but it can happen when loading other
packages that could be broken by the backport.

On one side we want a "reproducible" reliable version announced as "official release" at one point
in time on the other hand we want to be able to backport fixes and make the experience better
so Pharo 2.0 is not really fix.

IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but
for the artefacts (in the build folder) and on the download page we should provide the
FULL VERSION:

MAJOR.MINOR-BUILD

As you know we already use this for our development: the build is our update number which is also
easily reproducible (we have release mails like for 20627) and in the near future with projects
like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/
it will be even easier to get a specific image version.

So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we
should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way
people could spot the difference to old downloads more easily.

One often see's download pages of open source projects stating "Download latest here" and
"Download previous versions here" with a list of older releases.
By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want.

My proposal: lets use the update number more often. It would also help when people report bugs
to know about the specific update number.

It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the
newer one with the backports?" cycle ;)

Thx
T.

> Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr
> Von: "Noury Bouraqadi" <[hidden email]>
> An: "Pharo Development List" <[hidden email]>
> Betreff: [Pharo-dev] A thought about backporting
>
> Hi,
>
> Here is a thought I want to share with you.
> Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system.
>
> I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer?
> There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one).
>
> Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough.
> Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version.
>
> Noury
> Ecole des Mines de Douai
> http://car.mines-douai.fr/noury
> --
>
>
>
>
>

Stéphane Ducasse

Re: A thought about backporting

Yes this is probably a good idea to proceed like that.

Stef

On Nov 14, 2013, at 9:12 PM, Torsten Bergmann <[hidden email]> wrote:

> If a backport happens it can mean two things to a user:
>
> POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...)
> NEGATIV: a possible broken API introduced by a backport
>
> It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip"
> from http://files.pharo.org/platform directly after the "big announcement" and half year
> later (after backports happened) he may be surprised since it results in different images
> and may lead to problems. Not directly in the image but it can happen when loading other
> packages that could be broken by the backport.
>
>
> On one side we want a "reproducible" reliable version announced as "official release" at one point
> in time on the other hand we want to be able to backport fixes and make the experience better
> so Pharo 2.0 is not really fix.
>
>
> IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but
> for the artefacts (in the build folder) and on the download page we should provide the
> FULL VERSION:
>
> MAJOR.MINOR-BUILD
>
> As you know we already use this for our development: the build is our update number which is also
> easily reproducible (we have release mails like for 20627) and in the near future with projects
> like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/
> it will be even easier to get a specific image version.
>
>
> So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we
> should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way
> people could spot the difference to old downloads more easily.
>
> One often see's download pages of open source projects stating "Download latest here" and
> "Download previous versions here" with a list of older releases.
> By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want.
>
> My proposal: lets use the update number more often. It would also help when people report bugs
> to know about the specific update number.
>
> It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the
> newer one with the backports?" cycle ;)
>
> Thx
> T.
>
>
>> Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr
>> Von: "Noury Bouraqadi" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Betreff: [Pharo-dev] A thought about backporting
>>
>> Hi,
>>
>> Here is a thought I want to share with you.
>> Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system.
>>
>> I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer?
>> There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one).
>>
>> Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough.
>> Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version.
>>
>> Noury
>> Ecole des Mines de Douai
>> http://car.mines-douai.fr/noury
>> --
>>
>>
>>
>>
>>
>

kilon.alios

Re: A thought about backporting

Pharolauncher does make it clear which specific release the user downloads. Of course would not hurt to add the release to the name of the version or the name of the download. Also I used to like the notification pop up window when I first opened the image , there the specific release could be shown , maybe even a log with new changes , bug fixes, so the user is aware what exactly has downloaded.

Now when you open the image you are welcomed with an empty white space and pharo logo which I think is a bit too empty for my taste.

On Thu, Nov 14, 2013 at 10:22 PM, Stéphane Ducasse <[hidden email]> wrote:

Yes this is probably a good idea to proceed like that.

Stef

On Nov 14, 2013, at 9:12 PM, Torsten Bergmann <[hidden email]> wrote:

> If a backport happens it can mean two things to a user:
>
> POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...)
> NEGATIV: a possible broken API introduced by a backport
>
> It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip"
> from http://files.pharo.org/platform directly after the "big announcement" and half year
> later (after backports happened) he may be surprised since it results in different images
> and may lead to problems. Not directly in the image but it can happen when loading other
> packages that could be broken by the backport.
>
>
> On one side we want a "reproducible" reliable version announced as "official release" at one point
> in time on the other hand we want to be able to backport fixes and make the experience better
> so Pharo 2.0 is not really fix.
>
>
> IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but
> for the artefacts (in the build folder) and on the download page we should provide the
> FULL VERSION:
>
> MAJOR.MINOR-BUILD
>
> As you know we already use this for our development: the build is our update number which is also
> easily reproducible (we have release mails like for 20627) and in the near future with projects
> like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/
> it will be even easier to get a specific image version.
>
>
> So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we
> should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way
> people could spot the difference to old downloads more easily.
>
> One often see's download pages of open source projects stating "Download latest here" and
> "Download previous versions here" with a list of older releases.
> By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want.
>
> My proposal: lets use the update number more often. It would also help when people report bugs
> to know about the specific update number.
>
> It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the
> newer one with the backports?" cycle ;)
>
> Thx
> T.
>
>
>> Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr
>> Von: "Noury Bouraqadi" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Betreff: [Pharo-dev] A thought about backporting
>>
>> Hi,
>>
>> Here is a thought I want to share with you.
>> Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system.
>>
>> I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer?
>> There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one).
>>
>> Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough.
>> Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version.
>>
>> Noury
>> Ecole des Mines de Douai
>> http://car.mines-douai.fr/noury
>> --
>>
>>
>>
>>
>>
>

Camillo Bruni-3

Re: A thought about backporting

In reply to this post by Torsten Bergmann

You already have a complete list of the images here:

http://files.pharo.org/image/20/
http://files.pharo.org/image/30/

I don't think that the platform/oneclick builds should be the main deployment artifacts.

I assume that if you have a decent project you will use a CI service to build your project,
which means you can easily fix the image version by using the links above.

On 2013-11-14, at 21:12, Torsten Bergmann <[hidden email]> wrote:

signature.asc (457 bytes) Download Attachment

Ben Coman

Re: A thought about backporting

In reply to this post by Torsten Bergmann

OMG! I only just noticed on the "RELEASE" page [1] the linked file "Pharo2.0-win.zip" [3] has a last-modified-date of 2013-11-13. What crack [2] are you smoking? A "released" file with a name like "Pharo2.0-win.zip" should NEVER change its contents. NEVER! It SHOULD always remain the same - always - to the end of time! Backports are really important but they should be labelled as a new version "release" or just as "latest" if regularly uploaded from the CI.

There is much (good) talk about reproducibility in the Pharo development process, but what about the poor sysadmin who deals only with installing "released" versions of software? Where is his reproducibility for the documentation he produced specifying where to downloaded the EXACT software versions required to configure the Standard Operating Environment of a business. Documentation used by another half dozen people people who never use Pharo themselves?

A later "release" in the summer should have a different name, like 'Pharo2.0-summer-win.zip". Indeed why do you even bother calling it Pharo2.0 if there is never a Pharo 2.1 or later minor increment? Just dispense with it and call it Pharo2 and Pharo2-summer in the filenames.

It is fantastic that latest-build is available as an installer, but don't present it to user's as a "release". In many sysadmin situations it is better to have reproducibility with know issues - rather than randomness with some issues resolved but other new ones introduced to eat into your time investigating them.

As I near the end of writing this I now vaguely remember some past discussion on this, that seemed to make sense at the time - but I'm tired and had a bad day so perhaps my eye is more critical today. Maybe I just needed *something* to vent at. I know everyone is time-poor while achieving many great things with Pharo. I do appreciate it. I think now I'll go have a snooze.

regards -ben

[1] http://www.pharo-project.org/pharo-download/release-2-0
[2] http://en.wikipedia.org/wiki/Crack_cocaine
[3] http://files.pharo.org/platform/Pharo2.0-win.zip

Torsten Bergmann wrote:

If a backport happens it can mean two things to a user:

POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...)
NEGATIV: a possible broken API introduced by a backport

It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip"
from http://files.pharo.org/platform directly after the "big announcement" and half year
later (after backports happened) he may be surprised since it results in different images
and may lead to problems. Not directly in the image but it can happen when loading other
packages that could be broken by the backport.

On one side we want a "reproducible" reliable version announced as "official release" at one point
in time on the other hand we want to be able to backport fixes and make the experience better
so Pharo 2.0 is not really fix.

IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but
for the artefacts (in the build folder) and on the download page we should provide the
FULL VERSION:

MAJOR.MINOR-BUILD

As you know we already use this for our development: the build is our update number which is also
easily reproducible (we have release mails like for 20627) and in the near future with projects
like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/
it will be even easier to get a specific image version.

So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we
should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way
people could spot the difference to old downloads more easily.

One often see's download pages of open source projects stating "Download latest here" and
"Download previous versions here" with a list of older releases.
By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want.

My proposal: lets use the update number more often. It would also help when people report bugs
to know about the specific update number.

It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the
newer one with the backports?" cycle ;)

Thx
T.

Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr
Von: "Noury Bouraqadi" [hidden email]
An: "Pharo Development List" [hidden email]
Betreff: [Pharo-dev] A thought about backporting

Hi,

Here is a thought I want to share with you.
Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system.

I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer? 
There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one).

Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough. 
Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version.

Noury
Ecole des Mines de Douai
http://car.mines-douai.fr/noury
--

Stéphane Ducasse

Re: A thought about backporting

In reply to this post by Camillo Bruni-3

The point of noury is that it is better to have 2.0 and 2.1 and 2.2 and as few as possible
and to have that as a public interface.

After people can really pick a given version.

Stef

> You already have a complete list of the images here:
>
> http://files.pharo.org/image/20/
> http://files.pharo.org/image/30/
>
> I don't think that the platform/oneclick builds should be the main deployment artifacts.
>
> I assume that if you have a decent project you will use a CI service to build your project,
> which means you can easily fix the image version by using the links above.
>
> On 2013-11-14, at 21:12, Torsten Bergmann <[hidden email]> wrote:
>> If a backport happens it can mean two things to a user:
>>
>> POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...)
>> NEGATIV: a possible broken API introduced by a backport
>>
>> It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip"
>> from http://files.pharo.org/platform directly after the "big announcement" and half year
>> later (after backports happened) he may be surprised since it results in different images
>> and may lead to problems. Not directly in the image but it can happen when loading other
>> packages that could be broken by the backport.
>>
>>
>> On one side we want a "reproducible" reliable version announced as "official release" at one point
>> in time on the other hand we want to be able to backport fixes and make the experience better
>> so Pharo 2.0 is not really fix.
>>
>>
>> IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but
>> for the artefacts (in the build folder) and on the download page we should provide the
>> FULL VERSION:
>>
>> MAJOR.MINOR-BUILD
>>
>> As you know we already use this for our development: the build is our update number which is also
>> easily reproducible (we have release mails like for 20627) and in the near future with projects
>> like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/
>> it will be even easier to get a specific image version.
>>
>>
>> So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we
>> should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way
>> people could spot the difference to old downloads more easily.
>>
>> One often see's download pages of open source projects stating "Download latest here" and
>> "Download previous versions here" with a list of older releases.
>> By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want.
>>
>> My proposal: lets use the update number more often. It would also help when people report bugs
>> to know about the specific update number.
>>
>> It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the
>> newer one with the backports?" cycle ;)
>>
>> Thx
>> T.
>>
>>
>>> Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr
>>> Von: "Noury Bouraqadi" <[hidden email]>
>>> An: "Pharo Development List" <[hidden email]>
>>> Betreff: [Pharo-dev] A thought about backporting
>>>
>>> Hi,
>>>
>>> Here is a thought I want to share with you.
>>> Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system.
>>>
>>> I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer?
>>> There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one).
>>>
>>> Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough.
>>> Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version.
>>>
>>> Noury
>>> Ecole des Mines de Douai
>>> http://car.mines-douai.fr/noury
>>> --
>>>
>>>
>>>
>>>
>>>
>>
>

kilon.alios

Re: A thought about backporting

"what crack you are smoking" is not very nice. Being polite never hurts. This is a friendly community lets keep it this way.

On Fri, Nov 15, 2013 at 1:39 PM, Stéphane Ducasse <[hidden email]> wrote:

The point of noury is that it is better to have 2.0 and 2.1 and 2.2 and as few as possible
and to have that as a public interface.

After people can really pick a given version.

Stef

> You already have a complete list of the images here:
>
> http://files.pharo.org/image/20/
> http://files.pharo.org/image/30/
>
> I don't think that the platform/oneclick builds should be the main deployment artifacts.
>
> I assume that if you have a decent project you will use a CI service to build your project,
> which means you can easily fix the image version by using the links above.
>
> On 2013-11-14, at 21:12, Torsten Bergmann <[hidden email]> wrote:
>> If a backport happens it can mean two things to a user:
>>
>> POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...)
>> NEGATIV: a possible broken API introduced by a backport
>>
>> It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip"
>> from http://files.pharo.org/platform directly after the "big announcement" and half year
>> later (after backports happened) he may be surprised since it results in different images
>> and may lead to problems. Not directly in the image but it can happen when loading other
>> packages that could be broken by the backport.
>>
>>
>> On one side we want a "reproducible" reliable version announced as "official release" at one point
>> in time on the other hand we want to be able to backport fixes and make the experience better
>> so Pharo 2.0 is not really fix.
>>
>>
>> IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but
>> for the artefacts (in the build folder) and on the download page we should provide the
>> FULL VERSION:
>>
>> MAJOR.MINOR-BUILD
>>
>> As you know we already use this for our development: the build is our update number which is also
>> easily reproducible (we have release mails like for 20627) and in the near future with projects
>> like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/
>> it will be even easier to get a specific image version.
>>
>>
>> So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we
>> should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way
>> people could spot the difference to old downloads more easily.
>>
>> One often see's download pages of open source projects stating "Download latest here" and
>> "Download previous versions here" with a list of older releases.
>> By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want.
>>
>> My proposal: lets use the update number more often. It would also help when people report bugs
>> to know about the specific update number.
>>
>> It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the
>> newer one with the backports?" cycle ;)
>>
>> Thx
>> T.
>>
>>
>>> Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr
>>> Von: "Noury Bouraqadi" <[hidden email]>
>>> An: "Pharo Development List" <[hidden email]>
>>> Betreff: [Pharo-dev] A thought about backporting
>>>
>>> Hi,
>>>
>>> Here is a thought I want to share with you.
>>> Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system.
>>>
>>> I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer?
>>> There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one).
>>>
>>> Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough.
>>> Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version.
>>>
>>> Noury
>>> Ecole des Mines de Douai
>>> http://car.mines-douai.fr/noury
>>> --
>>>
>>>
>>>
>>>
>>>
>>
>

camille teruel

Re: A thought about backporting

On 15 nov. 2013, at 13:19, kilon alios <[hidden email]> wrote:

"what crack you are smoking" is not very nice. Being polite never hurts. This is a friendly community lets keep it this way.

I don't think it was said meanly but just to make a point.

Mails don't convey the intended tone well so to avoid further misunderstanding and to keep a friendly tone, I order everyone to use :) , ^^ , <joke></joke> and such extensively.

On Fri, Nov 15, 2013 at 1:39 PM, Stéphane Ducasse <[hidden email]> wrote:

The point of noury is that it is better to have 2.0 and 2.1 and 2.2 and as few as possible
and to have that as a public interface.

After people can really pick a given version.

Stef

> You already have a complete list of the images here:
>
> http://files.pharo.org/image/20/
> http://files.pharo.org/image/30/
>
> I don't think that the platform/oneclick builds should be the main deployment artifacts.
>
> I assume that if you have a decent project you will use a CI service to build your project,
> which means you can easily fix the image version by using the links above.
>
> On 2013-11-14, at 21:12, Torsten Bergmann <[hidden email]> wrote:
>> If a backport happens it can mean two things to a user:
>>
>> POSITIV: a valueable addition that makes an already released version better to use (fix, optimization, ...)
>> NEGATIV: a possible broken API introduced by a backport
>>
>> It's not the best solution we currently have. When a new user downloads a "Pharo2.0-win.zip"
>> from http://files.pharo.org/platform directly after the "big announcement" and half year
>> later (after backports happened) he may be surprised since it results in different images
>> and may lead to problems. Not directly in the image but it can happen when loading other
>> packages that could be broken by the backport.
>>
>>
>> On one side we want a "reproducible" reliable version announced as "official release" at one point
>> in time on the other hand we want to be able to backport fixes and make the experience better
>> so Pharo 2.0 is not really fix.
>>
>>
>> IMHO the solution is very easy: we can still communicate about "Pharo 3.0" or "Pharo 2.0" but
>> for the artefacts (in the build folder) and on the download page we should provide the
>> FULL VERSION:
>>
>> MAJOR.MINOR-BUILD
>>
>> As you know we already use this for our development: the build is our update number which is also
>> easily reproducible (we have release mails like for 20627) and in the near future with projects
>> like PharoLauncher https://ci.inria.fr/pharo-contribution/job/PharoLauncher/
>> it will be even easier to get a specific image version.
>>
>>
>> So "Pharo2.0 Latest update: #20627" in the about box already means "Pharo 2.0-627", so we
>> should have a "Pharo 2.0-627-win.zip" for the download to make it more clear. This way
>> people could spot the difference to old downloads more easily.
>>
>> One often see's download pages of open source projects stating "Download latest here" and
>> "Download previous versions here" with a list of older releases.
>> By using the Major.minor-build like "Pharo 2.0-627" people could pick up what they want.
>>
>> My proposal: lets use the update number more often. It would also help when people report bugs
>> to know about the specific update number.
>>
>> It would also avoid the "I have a problem in Pharo 2.0" and "the one from last year or the
>> newer one with the backports?" cycle ;)
>>
>> Thx
>> T.
>>
>>
>>> Gesendet: Donnerstag, 14. November 2013 um 20:05 Uhr
>>> Von: "Noury Bouraqadi" <[hidden email]>
>>> An: "Pharo Development List" <[hidden email]>
>>> Betreff: [Pharo-dev] A thought about backporting
>>>
>>> Hi,
>>>
>>> Here is a thought I want to share with you.
>>> Please don't misunderstand me. I'm really valuing the effort that people put into pharo, but I think sharing this will hopefully result in improving our system.
>>>
>>> I believe that back-porting is a false good idea. Consider simply this question: what is the 2.0 release? The latest version or the one release this summer?
>>> There are valuable bugfixes and enhancements that were integrated in the latest 2.0. But, I believe that this may cause some frustration among users since the API/features might evolve a bit (it happened to me, and it seems that I'm not the only one).
>>>
>>> Rather than changing 2.0, I suggest to introduce 2.1 if the community really believes that 2.0 isn't good enough.
>>> Same for future versions. Once we are confident enough with a RC, we should freeze it. Only critical bugfixes should be backported in yet another minor version.
>>>
>>> Noury
>>> Ecole des Mines de Douai
>>> http://car.mines-douai.fr/noury
>>> --
>>>
>>>
>>>
>>>
>>>
>>
>

Esteban A. Maringolo

Re: A thought about backporting

In reply to this post by Stéphane Ducasse

2013/11/15 Stéphane Ducasse <[hidden email]>
> The point of noury is that it is better to have 2.0 and 2.1 and 2.2 and as few as possible
> and to have that as a public interface.
>
> After people can really pick a given version.

+1 to this.

Now we have the build number, but it is not as semantically
representative as the "minor version" field.

Major.Minor-build would be better than what we have now.

Regards.

Stephan Eggermont-3

Re: A thought about backporting

In reply to this post by Noury Bouraqadi-2

btc wrote:

>OMG! I only just noticed on the "RELEASE" page [1] the linked file "Pharo2.0-win.zip" [3] >has a last-modified-date of 2013-11-13. What crack [2] are you smoking? A "released" >file with a name like "Pharo2.0-win.zip" should NEVER change its contents. NEVER! It >SHOULD always remain the same - always - to the end of time! Backports are really >important but they should be labelled as a new version "release" or just as "latest" if >regularly uploaded from the CI.

No. Releases on the website are for humans, not for automation. They should work and have all the latest backported bugfixes. Fixed versions for automation and sysadmins have build numbers. We have this covered with files.pharo.org

Please read Van den Hamer & Lepoeter (1996) Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration Management, and Product Data Management, Proceedings of the IEEE, Vol. 84, No 1, January 1996

Camillo Bruni-3

Re: A thought about backporting

On 2013-11-15, at 14:26, Stephan Eggermont <[hidden email]> wrote:

> btc wrote:
> >OMG! I only just noticed on the "RELEASE" page [1] the linked file "Pharo2.0-win.zip" [3] >has a last-modified-date of 2013-11-13. What crack [2] are you smoking? A "released" >file with a name like "Pharo2.0-win.zip" should NEVER change its contents. NEVER! It >SHOULD always remain the same - always - to the end of time! Backports are really >important but they should be labelled as a new version "release" or just as "latest" if >regularly uploaded from the CI.
>
> No. Releases on the website are for humans, not for automation. They should work and have all the latest backported bugfixes. Fixed versions for automation and sysadmins have build numbers. We have this covered with files.pharo.org

I agree

signature.asc (457 bytes) Download Attachment

Igor Stasenko

Re: A thought about backporting

On 15 November 2013 14:31, Camillo Bruni <[hidden email]> wrote:

On 2013-11-15, at 14:26, Stephan Eggermont <[hidden email]> wrote:

> btc wrote:
> >OMG! I only just noticed on the "RELEASE" page [1] the linked file "Pharo2.0-win.zip" [3] >has a last-modified-date of 2013-11-13. What crack [2] are you smoking? A "released" >file with a name like "Pharo2.0-win.zip" should NEVER change its contents. NEVER! It >SHOULD always remain the same - always - to the end of time! Backports are really >important but they should be labelled as a new version "release" or just as "latest" if >regularly uploaded from the CI.
>
> No. Releases on the website are for humans, not for automation. They should work and have all the latest backported bugfixes. Fixed versions for automation and sysadmins have build numbers. We have this covered with files.pharo.org

I agree

from perspective of automation i also completely agree with Stephan.

Just thought about it, what urls i used for downloads of other projects, and found it is usually bad idea to pick a download url from front page to build the rest of process on top of it.

Because sites often changing, means urls as well.. or people adding registration/pay walls etc..

while if you using urls pointing to archive, it is meant to be non-changing over longer time period (possibly forever).

--
Best regards,
Igor Stasenko.

Ben Coman

Re: A thought about backporting

In reply to this post by Camillo Bruni-3

Camillo Bruni wrote:

On 2013-11-15, at 14:26, Stephan Eggermont [hidden email] wrote:

btc wrote:

OMG! I only just noticed on the "RELEASE" page [1] the linked file "Pharo2.0-win.zip" [3] >has a last-modified-date of 2013-11-13.  What crack [2] are you smoking?  A "released" >file with a name like "Pharo2.0-win.zip" should NEVER change its contents.  NEVER!  It >SHOULD always remain the same - always - to the end of time! Backports are really >important but they should be labelled as a new version "release" or just as "latest" if >regularly uploaded from the CI.

No. Releases on the website are for humans, not for automation. They should work and have all the latest backported bugfixes. Fixed versions for automation and sysadmins have build numbers. We have this covered with files.pharo.org


I agree

My apologies for how badly that poured out of me. Reading it after a sleep on the couch I'm a bit embarrassed. I'll restate in a more considered way.

First, this doesn't affect me personally because I know about files.pharo.org and I use PharoLauncher. I was thinking more of newcomers and sysadmins (with whom I empathize with from a past work-life.) I understand your point contrasting humans and automation, and maybe I'm being pedantic, but I consider "Pharo2.0-win.zip" to be a fixed version. Its "fixed" version is "2.0". The "point-zero" makes it a fixed version. Right above it even says "released on Monday, March 18th 2013" - which turns out to be not true for that file. If you don't want the web site version to be a fixed version, then a better name would be Pharo2-latest-win.zip, or even just Pharo2-win.zip.

However fixed versions are also good for humans. Here is a scenario: Six months ago at home Alice downloaded Pharo - went to the web site, clicked on menu Download > Release 2.0 then downloaded Installer > Pharo 2.0-win.zip. While learning Pharo she made a simple-application. Today at work her colleague Bob gets interested in trying out Pharo, so they download the same release as Alice did so that Bob can try out her simple-application. As before - they go to the web site, click on menu Download > Release 2.0 then download Installer > Pharo 2.0-win.zip. Bob loads Alice's simple-application but it doesn't work. They are frustrated they do not understand why. Alice and Bob are both discouraged and move on, but whenever Pharo comes up in conversation they relate their experience.

Now that scenario is obviously contrived to make a point, and the real risk of such negative experience may be low, but I it shows why fixed versions are useful to humans, not just sysadmin automation. However my point is not actually whether or not there are fixed versions available from the web site. My point is that is "looks" like a fixed version when it is not.

In contrast, below under Custom Downloads > Virtual Machines it explicitly says "These links always point to the latest released Virtual machines" and there are no version numbers in the filename. That is good. Also under Custom Downloads > Image the filename is "Pharo-Image-2.0-latest.zip". That is good. My concern was with the one that looks like a fixed released but is not.

However in the big scheme of things Pharo is doing, this really is only a small thing and I should not have overreacted - and I've again just said more on it again than I meant to, so I'll leave it there.

cheers -ben

Sean P. DeNigris

Re: A thought about backporting

Administrator

btc wrote

My apologies for how badly that poured out of me.

We all have bad days :)

Actually, your passion may have awakened interest in this important topic. I agree with you - I've been pushing semantic versioning since Dale (IIRC) explained it to me. At the time, I think the barrier was adding to the burden of our poor integrators. But now that our CI process has become so automated, maybe this is the perfect time to revisit...

Cheers,
Sean

Stéphane Ducasse

Re: A thought about backporting

On Nov 15, 2013, at 7:05 PM, Sean P. DeNigris <[hidden email]> wrote:

> btc wrote
>> My apologies for how badly that poured out of me.
>
> We all have bad days :)

oh yes
What is strange is that I did not see the original mail.I wonder if I lose mails.

>
> Actually, your passion may have awakened interest in this important topic. I
> agree with you - I've been pushing semantic versioning since Dale (IIRC)
> explained it to me. At the time, I think the barrier was adding to the
> burden of our poor integrators. But now that our CI process has become so
> automated, maybe this is the perfect time to revisit...
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/A-thought-about-backporting-tp4722224p4722533.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

kilon.alios

Re: A thought about backporting

Yeap definetly I have my bad days too like everyone so its ok btc. :)

On Sat, Nov 16, 2013 at 6:59 PM, Stéphane Ducasse <[hidden email]> wrote:

On Nov 15, 2013, at 7:05 PM, Sean P. DeNigris <[hidden email]> wrote:

> btc wrote
>> My apologies for how badly that poured out of me.
>
> We all have bad days :)

oh yes
What is strange is that I did not see the original mail.I wonder if I lose mails.

>
> Actually, your passion may have awakened interest in this important topic. I
> agree with you - I've been pushing semantic versioning since Dale (IIRC)
> explained it to me. At the time, I think the barrier was adding to the
> burden of our poor integrators. But now that our CI process has become so
> automated, maybe this is the perfect time to revisit...
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/A-thought-about-backporting-tp4722224p4722533.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

Ben Coman

Re: A thought about backporting

kilon alios wrote:

Yeap definetly I have my bad days too like everyone so its ok btc. :)

Thanks & no problem. Your initial response was correct. The way to maintain community standards is to push them.
cheers -ben


On Sat, Nov 16, 2013 at 6:59 PM, Stéphane Ducasse <[hidden email]

wrote:

On Nov 15, 2013, at 7:05 PM, Sean P. DeNigris [hidden email]
wrote:

btc wrote

My apologies for how badly that poured out of me.

We all have bad days :)

oh yes
What is strange is that I did not see the original mail.I wonder if I lose
mails.

Actually, your passion may have awakened interest in this important

topic. I

agree with you - I've been pushing semantic versioning since Dale (IIRC)
explained it to me. At the time, I think the barrier was adding to the
burden of our poor integrators. But now that our CI process has become so
automated, maybe this is the perfect time to revisit...



-----
Cheers,
Sean
--
View this message in context:

http://forum.world.st/A-thought-about-backporting-tp4722224p4722533.html

Sent from the Pharo Smalltalk Developers mailing list archive at

Nabble.com.

Tudor Girba-2

Re: A thought about backporting

In reply to this post by Stéphane Ducasse

Hi Stef,

I think you should be happy that the finally you have a filter that filters out automatically all the negative energy mails :).

Cheers,

Doru

On Sat, Nov 16, 2013 at 5:59 PM, Stéphane Ducasse <[hidden email]> wrote:

On Nov 15, 2013, at 7:05 PM, Sean P. DeNigris <[hidden email]> wrote:

> btc wrote
>> My apologies for how badly that poured out of me.
>
> We all have bad days :)

oh yes
What is strange is that I did not see the original mail.I wonder if I lose mails.

>
> Actually, your passion may have awakened interest in this important topic. I
> agree with you - I've been pushing semantic versioning since Dale (IIRC)
> explained it to me. At the time, I think the barrier was adding to the
> burden of our poor integrators. But now that our CI process has become so
> automated, maybe this is the perfect time to revisit...
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/A-thought-about-backporting-tp4722224p4722533.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

www.tudorgirba.com

"Every thing has its own flow"

Stéphane Ducasse

Re: A thought about backporting

On Nov 16, 2013, at 7:48 PM, Tudor Girba <[hidden email]> wrote:

Hi Stef,

I think you should be happy that the finally you have a filter that filters out automatically all the negative energy mails :).

I would love to have this addons and also for the negative mails I sent :)

Stef

Cheers,
Doru

On Sat, Nov 16, 2013 at 5:59 PM, Stéphane Ducasse <[hidden email]> wrote:

On Nov 15, 2013, at 7:05 PM, Sean P. DeNigris <[hidden email]> wrote:

> btc wrote
>> My apologies for how badly that poured out of me.
>
> We all have bad days :)

oh yes
What is strange is that I did not see the original mail.I wonder if I lose mails.

>
> Actually, your passion may have awakened interest in this important topic. I
> agree with you - I've been pushing semantic versioning since Dale (IIRC)
> explained it to me. At the time, I think the barrier was adding to the
> burden of our poor integrators. But now that our CI process has become so
> automated, maybe this is the perfect time to revisit...
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/A-thought-about-backporting-tp4722224p4722533.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
>

--
www.tudorgirba.com

"Every thing has its own flow"