"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 <[email protected] > 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 <[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 > >>> -- > >>> > >>> > >>> > >>> > >>> > >> > > > > >
