[Pharo-dev] A thought about backporting

Stéphane Ducasse stephane.ducasse at inria.fr
Fri Nov 15 06:39:29 EST 2013


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