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 <asta...@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" <bouraq...@gmail.com> >> An: "Pharo Development List" <pharo-dev@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 >> -- >> >> >> >> >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
