[update 1.4] #14279

> Stéphane Ducasse wrote:
>> 14279
>> -----
>>
>> - Issue 5157: Finder > Class > right-click > Hierarchy opens not on Class but on FinderClassNode. Tx Benjamin van Ryseghem.
>> http://code.google.com/p/pharo/issues/detail?id=5157
>>
>>  
> This was reported by me on Pharo-1.3-13315 yesterday and closed overnight, so I'm impressed with the response time.  Now while this is hardly a critical issue I'm curious... now that it issue is marked closed, what is the plan to track these small fixes and roll them into a Pharo-1.3.1?   Once you get the business support model up and running I would imagine this task falls to the paid engineers.  (Release management is not exciting.) From a business perspective I would think that this is (almost) MORE important than the good refactoring work your doing to come out in a future version.
>
> There is a rule I've commonly seen in business to never use anything that is x.x.0.  Wait for the "first service release" is the mantra.  Seeing the versions go only from 1.3.0 to 1.4.0 to 1.5.0 does not instill business confidence in the stability of the platform.  Maybe you are willing to sacrifice that image at this early stage to move faster with limited resources, but just something to consider.
>
> keep up the good work,
> cheers, Ben
>

> for each bug we assess whether it is important or not for the previous version and if this is the case
> we batch some changes for the previous version.
> Now this is a lot of work and really few people help or seem concerned so we do as much as we
> can and it makes sense.
>
> Now I guess that this is always the case: people have to decide.
> Then integrating a fix for a bug that has not been discovered after 10 months does not imply anything on the
> stability of the system. Pharo 1.3 is stable, as 1.2 was and as 1.4 is.
>
>
> Stef
>
>> Stéphane Ducasse wrote:
>>> 14279
>>> -----
>>>
>>> - Issue 5157: Finder > Class > right-click > Hierarchy opens not on Class but on FinderClassNode. Tx Benjamin van Ryseghem.
>>> http://code.google.com/p/pharo/issues/detail?id=5157
>>>
>>>
>> This was reported by me on Pharo-1.3-13315 yesterday and closed overnight, so I'm impressed with the response time.  Now while this is hardly a critical issue I'm curious... now that it issue is marked closed, what is the plan to track these small fixes and roll them into a Pharo-1.3.1?   Once you get the business support model up and running I would imagine this task falls to the paid engineers.  (Release management is not exciting.) From a business perspective I would think that this is (almost) MORE important than the good refactoring work your doing to come out in a future version.
>>
>> There is a rule I've commonly seen in business to never use anything that is x.x.0.  Wait for the "first service release" is the mantra.  Seeing the versions go only from 1.3.0 to 1.4.0 to 1.5.0 does not instill business confidence in the stability of the platform.  Maybe you are willing to sacrifice that image at this early stage to move faster with limited resources, but just something to consider.
>>
>> keep up the good work,
>> cheers, Ben
>>
>
>

> Concerning my changes, I think they can be applied as they are for 1.3.
>
> I will test that this evening
>
>
>
> Ben
>
> On Jan 8, 2012, at 1:23 PM, Stéphane Ducasse wrote:
>
>  
>> for each bug we assess whether it is important or not for the previous version and if this is the case
>> we batch some changes for the previous version.
>> Now this is a lot of work and really few people help or seem concerned so we do as much as we
>> can and it makes sense.
>>
>> Now I guess that this is always the case: people have to decide.
>> Then integrating a fix for a bug that has not been discovered after 10 months does not imply anything on the
>> stability of the system. Pharo 1.3 is stable, as 1.2 was and as 1.4 is.
>>
>>
>> Stef
>>
>>    
>>> Stéphane Ducasse wrote:
>>>      
>>>> 14279
>>>> -----
>>>>
>>>> - Issue 5157: Finder > Class > right-click > Hierarchy opens not on Class but on FinderClassNode. Tx Benjamin van Ryseghem.
>>>> http://code.google.com/p/pharo/issues/detail?id=5157
>>>>
>>>>
>>>>        
>>> This was reported by me on Pharo-1.3-13315 yesterday and closed overnight, so I'm impressed with the response time.  Now while this is hardly a critical issue I'm curious... now that it issue is marked closed, what is the plan to track these small fixes and roll them into a Pharo-1.3.1?   Once you get the business support model up and running I would imagine this task falls to the paid engineers.  (Release management is not exciting.) From a business perspective I would think that this is (almost) MORE important than the good refactoring work your doing to come out in a future version.
>>>
>>> There is a rule I've commonly seen in business to never use anything that is x.x.0.  Wait for the "first service release" is the mantra.  Seeing the versions go only from 1.3.0 to 1.4.0 to 1.5.0 does not instill business confidence in the stability of the platform.  Maybe you are willing to sacrifice that image at this early stage to move faster with limited resources, but just something to consider.
>>>
>>> keep up the good work,
>>> cheers, Ben
>>>
>>>      
>>    
>
>
>
>