On 15 nov. 2013, at 13:19, kilon alios <[email protected]> wrote:
> "what crack you are smoking" is not very nice. Being polite never hurts. This > is a friendly community lets keep it this way. I don't think it was said meanly but just to make a point. Mails don't convey the intended tone well so to avoid further misunderstanding and to keep a friendly tone, I order everyone to use :) , ^^ , <joke></joke> and such extensively. :) > 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 > >>> -- > >>> > >>> > >>> > >>> > >>> > >> > > > > >
