Update the jenkins job to be multi-platform (though only loading #last):

https://ci.inria.fr/pharo-contribution/job/NBOpenGL


On 2013-05-17, at 09:10, Esteban Lorenzano <[email protected]> wrote:
> On May 16, 2013, at 11:53 PM, Igor Stasenko <[email protected]> wrote:
> 
>> On 15 May 2013 09:37, Esteban Lorenzano <[email protected]> wrote:
>>> 
>>> On May 14, 2013, at 12:45 AM, Igor Stasenko <[email protected]> wrote:
>>> 
>>>> How did you loaded NBOpenGL?
>>>> For 2.0/3.0 pharo image use
>>>> (ConfigurationOfNBOpenGL project version: '2.0') load
>>> 
>>> I added this important piece of information into 
>>> http://smalltalkhub.com/#!/~PharoExtras/NBOpenGL :)
>>> It would be a lot better to make
>>> 
>>> ConfigurationOfNBOpenGL load.
>>> 
>> 
>> unless you put a lot of complex logic behind that "load",
>> it will never work.
> 
> Why?
> load should be
> 
> ConfigurationOfNBOpenGL class>>#load 
>       ^ self project stableVersion load.
> 
> and nothing else
> 
>> That's why i prefer to giving a version numbers. This version of
>> config works with 2.0 image,
>> and no pain, no surprises.
>> Now, when people get used to do "ConfigurationOfNBOpenGL load"
>> it is less pain, but just for the next major update of whatever
>> infrastructural parts in Pharo.
> 
> again... why?
> Because what happens now is that people try to do what is the convention for 
> metacello. Also, that means that by not following the conventions, NBOpenGL 
> will never be able to be loaded through configuration browser :(
> 
>> 
>> And second, for me, as developer , it is much more helpful to deal
>> with problem reports like:
>> "this version doesn't loads/works with this version of image"
>> instead of "i tried and it doesn't works" :)
> 
> he, I'm sorry, I disagree... 
> If you as a developer promote a version as a release by assigning a #stable 
> symbolic version to configuration, you know exactly which version the guy is 
> trying to load. 
> And you will not have the problem "this version does not loads...", which is 
> a consequence of not declaring a version as stable for a platform. Looks to 
> me that the problem you try to avoid is in fact happening because the 
> configuration is not adapted to the convention, not the opposite :) 
> As proof... lot's of complex project follow the convention (seaside, for 
> example), and nobody has the issue you say. Recently they prepared the 
> configuration for 2.0, and that means that seaside now loads fine in 1.4 and 
> 2.0.... 
> 
> cheers,
> Esteban
> 
>> 
>>> work out of the box, and also to copy them to MetaRepoForPharo20... so 
>>> everybody can load without needing to thing a lot about.
>>> 
>>> Esteban
>> 
>> 
>> 
>> -- 
>> Best regards,
>> Igor Stasenko.
>> 
> 
> 


Reply via email to