[Pharo-dev] A thought about backporting

Stéphane Ducasse stephane.ducasse at inria.fr
Thu Nov 14 15:22:25 EST 2013


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

Stef

On Nov 14, 2013, at 9:12 PM, 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 
> 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 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
>> --
>> 
>> 
>> 
>> 
>> 
> 





More information about the Pharo-dev mailing list