[Pharo-dev] A thought about backporting

Camillo Bruni camillobruni at gmail.com
Fri Nov 15 04:07:25 EST 2013

You already have a complete list of the images here: 


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 at 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 
> 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 at gmail.com>
>> An: "Pharo Development List" <pharo-dev at 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
>> --

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 447 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131115/5ae947ac/attachment.asc>

More information about the Pharo-dev mailing list