[Pharo-project] About 1.4 Release...
Hi, We were discussing here about the 1.4 release... and my standpoint is: "What is on the Build Server will be the Release" For 1.4, this means that this image is the release image: https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact... possibly with more bugs fixed. the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 It especially means that we will not load additional packages (RB, OB....), because then we should have used the resulting image already the last months and we did not. Is that what we want? or will people say "without refactorings, I will not use it?" Marcus -- Marcus Denker -- http://marcusdenker.de
On 23 March 2012 09:34, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
We were discussing here about the 1.4 release... and my standpoint is:
    "What is on the Build Server will be the Release"
For 1.4, this means that this image is the release image:
    https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact...
possibly with more bugs fixed.
    the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4
It especially means that we will not load additional packages (RB, OB....), because then we should have used the resulting image already the last months and we did not.
Is that what we want? or will people say "without refactorings, I will not use it?"
I'd say "What is on the Build Server will be the Release" is exactly the right thing to do, because it's the thing you've been testing. You can have high confidence that the artifact will be stable, etc. Adding in extra stuff increases the testing burden. Of course, you (you, or some kind volunteer) could have a job that adds the various extras, and tests that Pharo+(stuff) image. frank
Ok, but that kind volunteer needs an image built the way they are told to do so. The convenience factor of having big stuff loaded into an image will attract users/testers. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shearar@gmail.com] Sent: Friday, March 23, 2012 6:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... On 23 March 2012 09:34, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
We were discussing here about the 1.4 release... and my standpoint is:
"What is on the Build Server will be the Release"
For 1.4, this means that this image is the release image:
https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact...
possibly with more bugs fixed.
the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4
It especially means that we will not load additional packages (RB, OB....), because then we should have used the resulting image already the last months and we did not.
Is that what we want? or will people say "without refactorings, I will not use it?"
I'd say "What is on the Build Server will be the Release" is exactly the right thing to do, because it's the thing you've been testing. You can have high confidence that the artifact will be stable, etc. Adding in extra stuff increases the testing burden. Of course, you (you, or some kind volunteer) could have a job that adds the various extras, and tests that Pharo+(stuff) image. frank
I'm working on cleaning ECompletion: now it works well in 1.4 So I guess that loading RBEngine and OB should make it. Now people should help. For 1.5 we will get nautilus. Stef
Ok, but that kind volunteer needs an image built the way they are told to do so. The convenience factor of having big stuff loaded into an image will attract users/testers.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shearar@gmail.com] Sent: Friday, March 23, 2012 6:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release...
On 23 March 2012 09:34, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
We were discussing here about the 1.4 release... and my standpoint is:
"What is on the Build Server will be the Release"
For 1.4, this means that this image is the release image:
https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact...
possibly with more bugs fixed.
the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4
It especially means that we will not load additional packages (RB, OB....), because then we should have used the resulting image already the last months and we did not.
Is that what we want? or will people say "without refactorings, I will not use it?"
I'd say "What is on the Build Server will be the Release" is exactly the right thing to do, because it's the thing you've been testing. You can have high confidence that the artifact will be stable, etc. Adding in extra stuff increases the testing burden.
Of course, you (you, or some kind volunteer) could have a job that adds the various extras, and tests that Pharo+(stuff) image.
frank
Stef, I'm not finding faults - merely encouraging good energy. For now, I am nudging a polymorph-friendly MVP framework (presenters as morph-model factories) and cleaning my GSL interface. The latter has to be done carefully, because I can't have GPL preventing me from commercial use of some of my more specialized consumers of its services. Sadly, that will limit what I can release, but I hope to provide something that will allow anyone to grab the library, install my packages (and probably a custom library to compensate for missing features and load problems on Linux), and do a lot with it. Re linux, it ships as two libraries, neither of which will load (dynamically) on its own over dependencies. They know about it, and don't seem to care. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Friday, March 23, 2012 8:21 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... I'm working on cleaning ECompletion: now it works well in 1.4 So I guess that loading RBEngine and OB should make it. Now people should help. For 1.5 we will get nautilus. Stef
Ok, but that kind volunteer needs an image built the way they are told to do so. The convenience factor of having big stuff loaded into an image will attract users/testers.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Frank Shearar [frank.shearar@gmail.com] Sent: Friday, March 23, 2012 6:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release...
On 23 March 2012 09:34, Marcus Denker <marcus.denker@inria.fr> wrote:
Hi,
We were discussing here about the 1.4 release... and my standpoint is:
"What is on the Build Server will be the Release"
For 1.4, this means that this image is the release image:
https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact...
possibly with more bugs fixed.
the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4
It especially means that we will not load additional packages (RB, OB....), because then we should have used the resulting image already the last months and we did not.
Is that what we want? or will people say "without refactorings, I will not use it?"
I'd say "What is on the Build Server will be the Release" is exactly the right thing to do, because it's the thing you've been testing. You can have high confidence that the artifact will be stable, etc. Adding in extra stuff increases the testing burden.
Of course, you (you, or some kind volunteer) could have a job that adds the various extras, and tests that Pharo+(stuff) image.
frank
Marcus, I like the idea of "downstream projects" but the dark side is that one won't know how much testing they have received. For one thing, the 1.4 Seaside image does not support Shout in system browsers (it works in the debugger) - 1.4 does have Shout everywhere. Someone suggested that the build scripts are not right, but my idealistic side asks why the downstream Seaside is not simply the latest 1.4 with Seaside loaded to save everybody time. I guess what I am saying is that you can pay now or pay later. Looking deeper, the pay later approach (which is what we are using) is that Pharo itself is consistent, but the end user gets stuck finding the things that would be found if Pharo were built and used (during development) in a more full featured way. I really miss the old web image, and would like to see a clean Pharo for those who must (Stef clearly finds it important - who am I to stand in his way), and a heavily advertised more fully featured image with RB, Seaside, Magritte, etc. loaded into it from the start. These are good tools that we want to promote, so we should get them tested as we go vs. dumping it on the user later. Re the RB, I enjoy having it, I choose not to use it very much. Older code accumulates lots of comments that have proven to save my skin in many situations. The RB's formatting has come a long way, but it still makes a mess of treasured resource in my old code. Refactorings that do not have to touch the code are great, and I am often willing to exploit the RB in new code that has not had time to accumulate valuable comments in cascades and other weird places. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Marcus Denker [marcus.denker@inria.fr] Sent: Friday, March 23, 2012 5:34 AM To: Pharo Development Subject: [Pharo-project] About 1.4 Release... Hi, We were discussing here about the 1.4 release... and my standpoint is: "What is on the Build Server will be the Release" For 1.4, this means that this image is the release image: https://ci.lille.inria.fr/pharo/job/Pharo%201.4/lastSuccessfulBuild/artifact... possibly with more bugs fixed. the list is here: http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.4 It especially means that we will not load additional packages (RB, OB....), because then we should have used the resulting image already the last months and we did not. Is that what we want? or will people say "without refactorings, I will not use it?" Marcus -- Marcus Denker -- http://marcusdenker.de
On 23/03/12 5:34 AM, Marcus Denker wrote:
Is that what we want? or will people say "without refactorings, I will not use it?"
I think the release needs to happen soon, so we can all have a new baseline. According to the Pharo consortium vision doc, the release plan (maybe not for 1.4, but in the future) is to become yearly with two bug fix releases. If this were in place, then "refactoring" would miss the boat. Is it a big enough item to delay a release? Personally, I use it if it's in the image, and miss it slightly if it's not there. That's because I often work on a stripped down image, so others may feel differently.
Yearly seems a little slow, but might be about right to allow lots of time for testing. There will always be Jenkins for those who need a fix (sometimes guilty myself). Bug fix releases would be appreciated. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Yanni Chiu [yanni@rogers.com] Sent: Friday, March 23, 2012 11:10 AM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] About 1.4 Release... On 23/03/12 5:34 AM, Marcus Denker wrote:
Is that what we want? or will people say "without refactorings, I will not use it?"
I think the release needs to happen soon, so we can all have a new baseline. According to the Pharo consortium vision doc, the release plan (maybe not for 1.4, but in the future) is to become yearly with two bug fix releases. If this were in place, then "refactoring" would miss the boat. Is it a big enough item to delay a release? Personally, I use it if it's in the image, and miss it slightly if it's not there. That's because I often work on a stripped down image, so others may feel differently.
participants (5)
-
Frank Shearar -
Marcus Denker -
Schwab,Wilhelm K -
Stéphane Ducasse -
Yanni Chiu