Silly tweet

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

Silly tweet

Stephan Eggermont-3
>Starting to retire 1.2 builds from ci server now that 1.3 is getting ready: http://t.co/fC6w9EQ

seem a bit silly. I assume (from Marcus' earlier post) that the retiring takes place sometime after the
release of 1.3? Providing these builds might lead to people using them, and in commercial
development we mostly use released versions to base on. Within much time are we expected to migrate after
a new release?

Stephan Eggermont
Reply | Threaded
Open this post in threaded view
|

Re: Silly tweet

Marcus Denker-4

On Jun 29, 2011, at 2:36 PM, Stephan Eggermont wrote:

>> Starting to retire 1.2 builds from ci server now that 1.3 is getting ready: http://t.co/fC6w9EQ
>
> seem a bit silly. I assume (from Marcus' earlier post) that the retiring takes place sometime after the
> release of 1.3?

We did it with 1.1... the problem is that the build server is getting really full if we keep everything.
And e.g. 1.2 did not change in weeks, so building it (unchanged) and running the tests (unchanged),
does that make sense?

We can keep it if people need... but this time we switch servers in addition, so links will change anyway.

> Providing these builds might lead to people using them, and in commercial
> development we mostly use released versions to base on. Within much time are we expected to migrate after
> a new release?
>

Nobody removed the release from the archive... just the build server.

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


Reply | Threaded
Open this post in threaded view
|

Re: Silly tweet

Schwab,Wilhelm K
Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server.  Sounds great.


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Marcus Denker [[hidden email]]
Sent: Wednesday, June 29, 2011 9:37 AM
To: [hidden email]
Subject: Re: [Pharo-project] Silly tweet

On Jun 29, 2011, at 2:36 PM, Stephan Eggermont wrote:

>> Starting to retire 1.2 builds from ci server now that 1.3 is getting ready: http://t.co/fC6w9EQ
>
> seem a bit silly. I assume (from Marcus' earlier post) that the retiring takes place sometime after the
> release of 1.3?

We did it with 1.1... the problem is that the build server is getting really full if we keep everything.
And e.g. 1.2 did not change in weeks, so building it (unchanged) and running the tests (unchanged),
does that make sense?

We can keep it if people need... but this time we switch servers in addition, so links will change anyway.

> Providing these builds might lead to people using them, and in commercial
> development we mostly use released versions to base on. Within much time are we expected to migrate after
> a new release?
>

Nobody removed the release from the archive... just the build server.

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.



Reply | Threaded
Open this post in threaded view
|

Re: Silly tweet

Igor Stasenko
On 29 June 2011 15:56, Schwab,Wilhelm K <[hidden email]> wrote:
> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server.  Sounds great.
>
Indeed. If people would like to use older releases, they should look
for another place, not for build server.
Since build server are there to build & test bleeding-edge (under
development) versions, but not ones which already released and years
old.


>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Marcus Denker [[hidden email]]
> Sent: Wednesday, June 29, 2011 9:37 AM
> To: [hidden email]
> Subject: Re: [Pharo-project] Silly tweet
>
> On Jun 29, 2011, at 2:36 PM, Stephan Eggermont wrote:
>
>>> Starting to retire 1.2 builds from ci server now that 1.3 is getting ready: http://t.co/fC6w9EQ
>>
>> seem a bit silly. I assume (from Marcus' earlier post) that the retiring takes place sometime after the
>> release of 1.3?
>
> We did it with 1.1... the problem is that the build server is getting really full if we keep everything.
> And e.g. 1.2 did not change in weeks, so building it (unchanged) and running the tests (unchanged),
> does that make sense?
>
> We can keep it if people need... but this time we switch servers in addition, so links will change anyway.
>
>> Providing these builds might lead to people using them, and in commercial
>> development we mostly use released versions to base on. Within much time are we expected to migrate after
>> a new release?
>>
>
> Nobody removed the release from the archive... just the build server.
>
>        Marcus
>
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Stephan Eggermont-3
In reply to this post by Stephan Eggermont-3
Igor wrote:
>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote:
>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server.  Sounds great.
>
>Indeed. If people would like to use older releases, they should look
>for another place, not for build server.
>Since build server are there to build & test bleeding-edge (under
>development) versions, but not ones which already released and years
>old.

Ok, so you simply do not want the builds to be used by others.
That's fine.

Stephan Eggermont




Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Igor Stasenko
On 30 June 2011 00:12, Stephan Eggermont <[hidden email]> wrote:

> Igor wrote:
>>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote:
>>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server.  Sounds great.
>>
>>Indeed. If people would like to use older releases, they should look
>>for another place, not for build server.
>>Since build server are there to build & test bleeding-edge (under
>>development) versions, but not ones which already released and years
>>old.
>
> Ok, so you simply do not want the builds to be used by others.

Its not about that we don't want users to download older versions
(they are available for download at pharo official site).

No. Builds purpose is to follow a development process:  new update -> new build.
Now since we're done with 1.2 (and even almost done with 1.3) there
will be no new versions for these lines,
since all development is now in 1.4.
So, there is no reason to keep jobs for 1.2 and then 1.3 on build
server, because there will be no activity around it.



> That's fine.
>
> Stephan Eggermont


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Hannes Hirzel
Does this imply that older versions are not maintained (e.g. with
1.2.n or 1.3.n releases) which include important bug fixes.

It seems so and from a practical point of view there is probably no
way around it....

--Hannes

On 6/29/11, Igor Stasenko <[hidden email]> wrote:

> On 30 June 2011 00:12, Stephan Eggermont <[hidden email]> wrote:
>> Igor wrote:
>>>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote:
>>>> Having an archive seems sufficient - those who need old versions for use
>>>> or research can get them; they don't have to be clogging up the build
>>>> server.  Sounds great.
>>>
>>>Indeed. If people would like to use older releases, they should look
>>>for another place, not for build server.
>>>Since build server are there to build & test bleeding-edge (under
>>>development) versions, but not ones which already released and years
>>>old.
>>
>> Ok, so you simply do not want the builds to be used by others.
>
> Its not about that we don't want users to download older versions
> (they are available for download at pharo official site).
>
> No. Builds purpose is to follow a development process:  new update -> new
> build.
> Now since we're done with 1.2 (and even almost done with 1.3) there
> will be no new versions for these lines,
> since all development is now in 1.4.
> So, there is no reason to keep jobs for 1.2 and then 1.3 on build
> server, because there will be no activity around it.
>
>
>
>> That's fine.
>>
>> Stephan Eggermont
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Schwab,Wilhelm K
In reply to this post by Igor Stasenko
+1 to Sig's answer.  Old builds are great, and we should (and do) keep them around, but they do not need to be on the CI server.   As Sig said, the old versions don't change, so CI gets pretty boring.

The old versions are available from an archive (https://gforge.inria.fr/frs/?group_id=1299).  See the "file server" link on the downloads page.



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
Sent: Wednesday, June 29, 2011 6:16 PM
To: [hidden email]
Subject: Re: [Pharo-project] Silly Tweet

On 30 June 2011 00:12, Stephan Eggermont <[hidden email]> wrote:

> Igor wrote:
>>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote:
>>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server.  Sounds great.
>>
>>Indeed. If people would like to use older releases, they should look
>>for another place, not for build server.
>>Since build server are there to build & test bleeding-edge (under
>>development) versions, but not ones which already released and years
>>old.
>
> Ok, so you simply do not want the builds to be used by others.

Its not about that we don't want users to download older versions
(they are available for download at pharo official site).

No. Builds purpose is to follow a development process:  new update -> new build.
Now since we're done with 1.2 (and even almost done with 1.3) there
will be no new versions for these lines,
since all development is now in 1.4.
So, there is no reason to keep jobs for 1.2 and then 1.3 on build
server, because there will be no activity around it.



> That's fine.
>
> Stephan Eggermont


--
Best regards,
Igor Stasenko AKA sig.


Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Schwab,Wilhelm K
In reply to this post by Hannes Hirzel
There are 1.1.1 and 1.2.1 releases.  What I do not know is how, for example, 1.2.1 compares with the 1.2 on the CI server??

Bill



________________________________________
From: [hidden email] [[hidden email]] On Behalf Of H. Hirzel [[hidden email]]
Sent: Wednesday, June 29, 2011 6:23 PM
To: [hidden email]
Subject: Re: [Pharo-project] Silly Tweet

Does this imply that older versions are not maintained (e.g. with
1.2.n or 1.3.n releases) which include important bug fixes.

It seems so and from a practical point of view there is probably no
way around it....

--Hannes

On 6/29/11, Igor Stasenko <[hidden email]> wrote:

> On 30 June 2011 00:12, Stephan Eggermont <[hidden email]> wrote:
>> Igor wrote:
>>>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote:
>>>> Having an archive seems sufficient - those who need old versions for use
>>>> or research can get them; they don't have to be clogging up the build
>>>> server.  Sounds great.
>>>
>>>Indeed. If people would like to use older releases, they should look
>>>for another place, not for build server.
>>>Since build server are there to build & test bleeding-edge (under
>>>development) versions, but not ones which already released and years
>>>old.
>>
>> Ok, so you simply do not want the builds to be used by others.
>
> Its not about that we don't want users to download older versions
> (they are available for download at pharo official site).
>
> No. Builds purpose is to follow a development process:  new update -> new
> build.
> Now since we're done with 1.2 (and even almost done with 1.3) there
> will be no new versions for these lines,
> since all development is now in 1.4.
> So, there is no reason to keep jobs for 1.2 and then 1.3 on build
> server, because there will be no activity around it.
>
>
>
>> That's fine.
>>
>> Stephan Eggermont
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Yanni Chiu
In reply to this post by Schwab,Wilhelm K
On 29/06/11 6:24 PM, Schwab,Wilhelm K wrote:
> +1 to Sig's answer.  Old builds are great, and we should (and do)
> keep them around, but they do not need to be on the CI server.   As
> Sig said, the old versions don't change, so CI gets pretty boring.

There is the option to disable the build job, so that no further builds
take place (until there are maintenance releases to build).

There is also the option to use the CI server as the build archive as
well. You can mark some build numbers as "never remove". Normally, only
the last N builds are kept, and the oldest is deleted after the new
build completes (unless that oldest build is the last successful build,
then it's kept until the next successful build). Whichever builds are
marked "never remove" would form the archive. That would eliminate the
apparent confusion caused by having the archive at
https://gforge.inria.fr/frs/?group_id=1299

The other factor is that a transition to Jenkins from Hudson is
happening, which is driving the desire to drop the Hudson based 1.2 builds.


Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Igor Stasenko
On 30 June 2011 03:30, Yanni Chiu <[hidden email]> wrote:

> On 29/06/11 6:24 PM, Schwab,Wilhelm K wrote:
>>
>> +1 to Sig's answer.  Old builds are great, and we should (and do)
>> keep them around, but they do not need to be on the CI server.   As
>> Sig said, the old versions don't change, so CI gets pretty boring.
>
> There is the option to disable the build job, so that no further builds take
> place (until there are maintenance releases to build).
>
> There is also the option to use the CI server as the build archive as well.
> You can mark some build numbers as "never remove". Normally, only the last N
> builds are kept, and the oldest is deleted after the new build completes
> (unless that oldest build is the last successful build, then it's kept until
> the next successful build). Whichever builds are marked "never remove" would
> form the archive. That would eliminate the apparent confusion caused by
> having the archive at https://gforge.inria.fr/frs/?group_id=1299
>
> The other factor is that a transition to Jenkins from Hudson is happening,
> which is driving the desire to drop the Hudson based 1.2 builds.
>

Another aspect of it, that build servers has a limited space (Marcus
has to cut the number of builds , since they taking too much space).
While on gforge we can afford to keep much more.
Of course keeping latest 'frozen' build doesn't takes too much ,
except of a little nuisiance after a couple of years
every time you open a jenkins, you will see a very long list of jobs,
where only few of them actually needed.
That's why i thinking that moving things to archive is preferable.

In any way, i think everyone understands that nobody wants to hide
existing versions from public eyes.
Its only a question of finding appropriate place for them, after
development is done.

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Marcus Denker-4
In reply to this post by Yanni Chiu

On Jun 30, 2011, at 3:06 AM, Igor Stasenko wrote:

>
> Another aspect of it, that build servers has a limited space (Marcus
> has to cut the number of builds , since they taking too much space).
> While on gforge we can afford to keep much more.
> Of course keeping latest 'frozen' build doesn't takes too much ,
> except of a little nuisiance after a couple of years
> every time you open a jenkins, you will see a very long list of jobs,
> where only few of them actually needed.
> That's why i thinking that moving things to archive is preferable.
>
> In any way, i think everyone understands that nobody wants to hide
> existing versions from public eyes.
> Its only a question of finding appropriate place for them, after
> development is done.

Yes... we can keep 1.2 a bit. But what I don't want to keep are builds
*on top* of 1.2. (the only left now is AIDA, but I removed already some).

The amount of project on the build server is already very high:
        https://pharo-ic.lille.inria.fr/hudson/

and that with almost all 1.2 clients deleted and stuff moved to Jenkins:

        https://ci.lille.inria.fr/pharo/

But it's fun how something is seen as indespensable that we did not
have some month ago (and that some people thought is not important
*and* in the Squeak past even actively blocked from happening).

How times change... ;-)

What this shows is that what Jenkins/Hudson provide is essential,
and we should think about to move that somehow deeper into our
language... (nice research topic)

        Marcus


--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Stéphane Ducasse
In reply to this post by Stephan Eggermont-3

On Jun 29, 2011, at 11:12 PM, Stephan Eggermont wrote:

> Igor wrote:
>> On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote:
>>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server.  Sounds great.
>>
>> Indeed. If people would like to use older releases, they should look
>> for another place, not for build server.
>> Since build server are there to build & test bleeding-edge (under
>> development) versions, but not ones which already released and years
>> old.
>
> Ok, so you simply do not want the builds to be used by others.
> That's fine.

why do you say that?

What is the point to have a build server build all the time the same same same same same
same same image?

For the sake of it?

Stef

>
> Stephan Eggermont
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Mariano Martinez Peck
In reply to this post by Igor Stasenko


On Thu, Jun 30, 2011 at 12:16 AM, Igor Stasenko <[hidden email]> wrote:
On 30 June 2011 00:12, Stephan Eggermont <[hidden email]> wrote:
> Igor wrote:
>>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote:
>>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server.  Sounds great.
>>
>>Indeed. If people would like to use older releases, they should look
>>for another place, not for build server.
>>Since build server are there to build & test bleeding-edge (under
>>development) versions, but not ones which already released and years
>>old.
>
> Ok, so you simply do not want the builds to be used by others.

Its not about that we don't want users to download older versions
(they are available for download at pharo official site).

No. Builds purpose is to follow a development process:  new update -> new build.
Now since we're done with 1.2 (and even almost done with 1.3) there
will be no new versions for these lines,
since all development is now in 1.4.
So, there is no reason to keep jobs for 1.2 and then 1.3 on build
server, because there will be no activity around it.


What I understood is that there could be activity and changes not in pharo, but in the other project that is build/tested in Pharo.
Say I am still quite developing Fuel, and I am commiting every day. No matter if it is on Pharo 1.2 or 1.3 what I want to say is that there is activity.
Ok, the resources let us to that with the latest Pharo, so that we can test both at the same time: pharo itself and the third party.
If you want third part with old pharo images, then you should get your own IC server.


 


> That's fine.
>
> Stephan Eggermont


--
Best regards,
Igor Stasenko AKA sig.




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Fernando olivero-2
In reply to this post by Stéphane Ducasse
Why do people still use an older image?  Even as older as Pharo1.1 and 1.2.

It doesn't take much to update to Pharo1.3 or Pharo1.4, and its
totally worth the nuisance of updating a couple of classes references
and uses, because of the many many many improvements that get
integrated ( thanks for Marcus and Stef for the continuos improvements
integration and fixes)

Fernando


On Thu, Jun 30, 2011 at 9:10 AM, Stéphane Ducasse
<[hidden email]> wrote:

>
> On Jun 29, 2011, at 11:12 PM, Stephan Eggermont wrote:
>
>> Igor wrote:
>>> On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote:
>>>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server.  Sounds great.
>>>
>>> Indeed. If people would like to use older releases, they should look
>>> for another place, not for build server.
>>> Since build server are there to build & test bleeding-edge (under
>>> development) versions, but not ones which already released and years
>>> old.
>>
>> Ok, so you simply do not want the builds to be used by others.
>> That's fine.
>
> why do you say that?
>
> What is the point to have a build server build all the time the same same same same same
> same same image?
>
> For the sake of it?
>
> Stef
>
>>
>> Stephan Eggermont
>>
>>
>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Marcus Denker-4
In reply to this post by Stéphane Ducasse

On Jun 30, 2011, at 9:57 AM, Fernando Olivero wrote:

> Why do people still use an older image?  Even as older as Pharo1.1 and 1.2.
>
> It doesn't take much to update to Pharo1.3 or Pharo1.4, and its
> totally worth the nuisance of updating a couple of classes references
> and uses, because of the many many many improvements that get
> integrated ( thanks for Marcus and Stef for the continuos improvements
> integration and fixes)

In a commercial setting, things are different... people need to really think hard
to move to a new system. Time is money, bugs are expensive, there is always
a deadline more important...

One thing we want to do with Pharo over the next years is to actually make it easy
to stay at an old version. And easy to gradually move to new versions.

It's an interesting question how a language and system can support software evolution
*for real*.

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Marcus Denker-4
In reply to this post by Igor Stasenko

On Jun 30, 2011, at 9:53 AM, Mariano Martinez Peck wrote:
>
> What I understood is that there could be activity and changes not in pharo, but in the other project that is build/tested in Pharo.
> Say I am still quite developing Fuel, and I am commiting every day. No matter if it is on Pharo 1.2 or 1.3 what I want to say is that there is activity.
> Ok, the resources let us to that with the latest Pharo, so that we can test both at the same time: pharo itself and the third party.
> If you want third part with old pharo images, then you should get your own IC server.
>
It would be nice to have CI infrastructure available for everyone to just use. But this can not be me who edits text files by hand for such a
service...

        Marcus


--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Stephan Eggermont-3
In reply to this post by Stephan Eggermont-3
Stef wrote in response to my:
>> Ok, so you simply do not want the builds to be used by others.
>>That's fine.

>why do you say that?

Such a build server can have two purposes:
- to directly help with the development of the software named in the build jobs;
- it can provide a starting point for others to base their work on.

Both are valuable, and it is acceptable if you want to want to focus on the first.
For the second, as a commercial developer I have to be able to make my upgrade
schedule as independent as possible from that of the projects I depend on.
Depending on artifacts with an unknown availability is not possible.

>What is the point to have a build server build all the time the same same same same same
>same same image?

A build server is used as we've learned there is no such thing as the same same image.
There have been regressions because of vm changes or operating system updates,
and I've seen 1.2.1 and 1.2.2. Also, while Pharo might be the same, both Zinc and Seaside
change.

Stephan




Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

NorbertHartl

Am 30.06.2011 um 10:32 schrieb Stephan Eggermont:

> Stef wrote in response to my:
>>> Ok, so you simply do not want the builds to be used by others.
>>> That's fine.
>
>> why do you say that?
>
> Such a build server can have two purposes:
> - to directly help with the development of the software named in the build jobs;
> - it can provide a starting point for others to base their work on.
>
> Both are valuable, and it is acceptable if you want to want to focus on the first.
> For the second, as a commercial developer I have to be able to make my upgrade
> schedule as independent as possible from that of the projects I depend on.
> Depending on artifacts with an unknown availability is not possible.
>
Exactly. And that is the reason why it will be very hard not to have your own CI server. The official distribution will rarely match your requirements. We all patch packages here and there. That you can only deal with in your own setting.
All CI servers that I know (most of big development teams) face sooner or later the same thing. You might think disk space is endless or CPU but it is not. I don't know any bigger CI server that still builds all commits. It is just not possible because CPU and disk space isn't there enough. From that angle it is even more important to remove the things that aren't really needed.
I think you are actually looking for a reliable download location and the CI server is the wrong place for it. That's why there are last successful builds. The can be copied to a download server and rest forever.

my 2 cents,

Norbert

>> What is the point to have a build server build all the time the same same same same same
>> same same image?
>
> A build server is used as we've learned there is no such thing as the same same image.
> There have been regressions because of vm changes or operating system updates,
> and I've seen 1.2.1 and 1.2.2. Also, while Pharo might be the same, both Zinc and Seaside
> change.
>
> Stephan
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Silly Tweet

Adrian Lienhard
In reply to this post by Marcus Denker-4

On Jun 30, 2011, at 10:15 , Marcus Denker wrote:

> On Jun 30, 2011, at 9:57 AM, Fernando Olivero wrote:
>
>> Why do people still use an older image?  Even as older as Pharo1.1 and 1.2.
>>
>> It doesn't take much to update to Pharo1.3 or Pharo1.4, and its
>> totally worth the nuisance of updating a couple of classes references
>> and uses, because of the many many many improvements that get
>> integrated ( thanks for Marcus and Stef for the continuos improvements
>> integration and fixes)
>
> In a commercial setting, things are different... people need to really think hard
> to move to a new system. Time is money, bugs are expensive, there is always
> a deadline more important...

Exactly.

When you have systems of the size >1000 classes that have been grown over years and have to work reliably, just "updating a couple of classes [sic] references and uses" is not easy. First of all, you have to figure out *what* to change. Changes like a modified Dictionary/Set hierarchy can subtly break your code (leading to data corruption in our case [1]). Or, just because you are one of the first to use the new code under high load, you see problems others haven't seen before (leading to unresponsive images in our case [2]). Those are obvious external bugs, but we also ran into issues with our code just not being compatible anymore with new semantics (e.g., Number class>>#readFrom:).

That's why in a non-trivial setup, upgrading is costly, and at times painful (in particular when you missed problems in testing and then experience them in production).

[1] http://code.google.com/p/pharo/issues/detail?id=3658
[2] http://code.google.com/p/pharo/issues/detail?id=3498

Cheers,
Adrian
12