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