[Pharo-dev] A thought about backporting

Camille Teruel camille.teruel at gmail.com
Fri Nov 15 08:03:03 EST 2013


On 15 nov. 2013, at 13:19, kilon alios <kilon.alios at 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 at 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 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
> >>> --
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131115/17f1ade1/attachment-0002.html>


More information about the Pharo-dev mailing list