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