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 --
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" <bouraqadi@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 --
Yes this is probably a good idea to proceed like that. Stef On Nov 14, 2013, at 9:12 PM, Torsten Bergmann <astares@gmx.de> 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" <bouraqadi@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 --
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 < stephane.ducasse@inria.fr> wrote:
Yes this is probably a good idea to proceed like that.
Stef
On Nov 14, 2013, at 9:12 PM, Torsten Bergmann <astares@gmx.de> 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" <bouraqadi@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 --
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 <astares@gmx.de> 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" <bouraqadi@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 --
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 <astares@gmx.de> 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" <bouraqadi@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 --
"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 <stephane.ducasse@inria.fr
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 <astares@gmx.de> 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" <bouraqadi@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 --
On 15 nov. 2013, at 13:19, kilon alios <kilon.alios@gmail.com> 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 <stephane.ducasse@inria.fr> 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 <astares@gmx.de> 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" <bouraqadi@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 --
2013/11/15 Stéphane Ducasse <stephane.ducasse@inria.fr>
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.
participants (8)
-
btc＠openinworld.com -
Camille Teruel -
Camillo Bruni -
Esteban A. Maringolo -
kilon alios -
Noury Bouraqadi -
Stéphane Ducasse -
Torsten Bergmann