Pharolauncher does make it clear which specific release the user downloads. Of course would not hurt to add the release to the name of the version or the name of the download. Also I used to like the notification pop up window when I first opened the image , there the specific release could be shown , maybe even a log with new changes , bug fixes, so the user is aware what exactly has downloaded.
Now when you open the image you are welcomed with an empty white space and pharo logo which I think is a bit too empty for my taste. On Thu, Nov 14, 2013 at 10:22 PM, Stéphane Ducasse < [email protected]> wrote: > Yes this is probably a good idea to proceed like that. > > Stef > > On Nov 14, 2013, at 9:12 PM, Torsten Bergmann <[email protected]> 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" <[email protected]> > >> An: "Pharo Development List" <[email protected]> > >> 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 > >> -- > >> > >> > >> > >> > >> > > > > >
