About 1.4 Release...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

About 1.4 Release...

Marcus Denker-4
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/Pharo-1.4.zip

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


Reply | Threaded
Open this post in threaded view
|

Re: About 1.4 Release...

Frank Shearar-3
On 23 March 2012 09:34, Marcus Denker <[hidden email]> 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/Pharo-1.4.zip
>
> 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

Reply | Threaded
Open this post in threaded view
|

Re: About 1.4 Release...

Schwab,Wilhelm K
In reply to this post by Marcus Denker-4
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: [hidden email] [[hidden email]] on behalf of Marcus Denker [[hidden email]]
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/Pharo-1.4.zip

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



Reply | Threaded
Open this post in threaded view
|

Re: About 1.4 Release...

Schwab,Wilhelm K
In reply to this post by Frank Shearar-3
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: [hidden email] [[hidden email]] on behalf of Frank Shearar [[hidden email]]
Sent: Friday, March 23, 2012 6:25 AM
To: [hidden email]
Subject: Re: [Pharo-project] About 1.4 Release...

On 23 March 2012 09:34, Marcus Denker <[hidden email]> 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/Pharo-1.4.zip
>
> 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


Reply | Threaded
Open this post in threaded view
|

Re: About 1.4 Release...

Stéphane Ducasse
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: [hidden email] [[hidden email]] on behalf of Frank Shearar [[hidden email]]
> Sent: Friday, March 23, 2012 6:25 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] About 1.4 Release...
>
> On 23 March 2012 09:34, Marcus Denker <[hidden email]> 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/Pharo-1.4.zip
>>
>> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: About 1.4 Release...

Yanni Chiu
In reply to this post by Marcus Denker-4
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.


Reply | Threaded
Open this post in threaded view
|

Re: About 1.4 Release...

Schwab,Wilhelm K
In reply to this post by Stéphane Ducasse
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: [hidden email] [[hidden email]] on behalf of Stéphane Ducasse [[hidden email]]
Sent: Friday, March 23, 2012 8:21 AM
To: [hidden email]
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: [hidden email] [[hidden email]] on behalf of Frank Shearar [[hidden email]]
> Sent: Friday, March 23, 2012 6:25 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] About 1.4 Release...
>
> On 23 March 2012 09:34, Marcus Denker <[hidden email]> 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/Pharo-1.4.zip
>>
>> 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
>
>



Reply | Threaded
Open this post in threaded view
|

Re: About 1.4 Release...

Schwab,Wilhelm K
In reply to this post by Yanni Chiu
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: [hidden email] [[hidden email]] on behalf of Yanni Chiu [[hidden email]]
Sent: Friday, March 23, 2012 11:10 AM
To: [hidden email]
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.