[Pharo-dev] A thought about backporting
kilon.alios at gmail.com
Fri Nov 15 07:19:59 EST 2013
"what crack you are smoking" is not very nice. Being polite never hurts.
This is a friendly community lets keep it this way.
On Fri, Nov 15, 2013 at 1:39 PM, Stéphane Ducasse <stephane.ducasse at inria.fr
> 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.
> > 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
> > 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
> >> 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...
More information about the Pharo-dev