November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] A thought about backporting

by Esteban A. Maringolo

2013/11/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > 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. +1 to this. Now we have the build number, but it is not as semantically representative as the "minor version" field. Major.Minor-build would be better than what we have now. Regards.

Nov. 15, 2013

Re: [Pharo-dev] A thought about backporting

by Camille Teruel

On 15 nov. 2013, at 13:19, kilon alios <kilon.alios(a)gmail.com> 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 <stephane.ducasse(a)inria.fr> 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 <astares(a)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" <bouraqadi(a)gmail.com> > >>> An: "Pharo Development List" <pharo-dev(a)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 > >>> -- > >>> > >>> > >>> > >>> > >>> > >> > > > > >

Nov. 15, 2013

Re: [Pharo-dev] Commit Rights for Pharo30Inbox

by Camillo Bruni

hi, can I have your smalltalkhub username? On 2013-11-15, at 13:30, NicolÃ¡s Papagna Maldonado <nicolas.papagna(a)gmail.com> wrote: > Hi all, > > I've been working of a bug fix and I reached the point I need to commit the slice :) > Could someone grant me commit rights in the Pharo30Inbox please? > > Thanks in advance, > > Nico PM

Nov. 15, 2013

Commit Rights for Pharo30Inbox

by NicolÃ¡s Papagna Maldonado

Hi all, I've been working of a bug fix and I reached the point I need to commit the slice :) Could someone grant me commit rights in the Pharo30Inbox please? Thanks in advance, Nico PM

Nov. 15, 2013

Re: [Pharo-dev] A thought about backporting

by kilon alios

"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 <stephane.ducasse(a)inria.fr > 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 <astares(a)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" <bouraqadi(a)gmail.com> > >>> An: "Pharo Development List" <pharo-dev(a)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 > >>> -- > >>> > >>> > >>> > >>> > >>> > >> > > > > >

Nov. 15, 2013

Re: [Pharo-dev] Commit permissions to Pharo30Inbox

by Juraj Kubelka

Thank you Marcus, Jura El 15-11-2013, a las 4:04, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > > On 15 Nov 2013, at 02:36, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > >> Hi, >> >> can someone give me a commit permissions to Pharo30Inbox? >> >> My account is http://smalltalkhub.com/#!/~JurajKubelka > > Done > > Marcus >

Nov. 15, 2013

Re: [Pharo-dev] Latest Xcode to Compile VM

by GÃ¶ran Krampe

On 11/06/2013 03:28 AM, Sean P. DeNigris wrote: > Yes, no compiling during holidays! We don't want you burning out. In > fact the no work of any kind... unless it's releasing Mars ;) but still > better after holiday... > > Will you let me know after you've successfully compiled with latest > Xcode so I can upgrade. Thanks. I am using Xcode ... 5.0 and it works. regards, GÃ¶ran

Nov. 15, 2013

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30576 Home: https://github.com/pharo-project/pharo-core

Nov. 15, 2013

[pharo-project/pharo-core] 1afd20: 30576

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 1afd20cec16208a17b633da307127a0f62d1748a https://github.com/pharo-project/pharo-core/commit/1afd20cec16208a17b633da3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-15 (Fri, 15 Nov 2013) Changed paths: M Kernel.package/Number.class/class/instance creation/readFrom_ifFail_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script232.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30576.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tests.package/ReleaseTest.class/instance/testing/testObsoleteBehaviors.st M Tests.package/ReleaseTest.class/instance/testing/testUnknownProcesses.st Log Message: ----------- 30576 12172 relax #testUnknownProcesses a little https://pharo.fogbugz.com/f/cases/12172 12171 Fix last reference to ExtendedNumberParser https://pharo.fogbugz.com/f/cases/12171 12165 #testObsoleteBehaviors failing after running native boost tests https://pharo.fogbugz.com/f/cases/12165 http://files.pharo.org/image/30/30576.zip

Nov. 15, 2013

Jenkins build is back to stable : Pharo-2.0-Tests Â» run 1,vm,linux #279

by no-reply＠ci.inria.fr

See <https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/Run=run%201,VM=vm,label=linux…>

Nov. 15, 2013