Unfortunately, you cannot release with one click multiple deeply nested
configurations. We will have to solve this problem soon :)

Cheers,
Doru

On Sun, Feb 22, 2015 at 8:33 PM, stepharo <[email protected]> wrote:

>  Doru with versioner you can release in a click...
>
> Le 8/2/15 13:01, Tudor Girba a écrit :
>
> Hi Nicolai,
>
>
>
> On Thu, Feb 5, 2015 at 9:36 PM, Nicolai Hess <[email protected]> wrote:
>
>>  14850 <https://pharo.fogbugz.com/default.asp?14850> Integrate GTools
>> #development
>> "From this version onwards the development version should be integrated."
>>
>>  Is this a good idea? Does the #development version always include *all*
>> the latest
>> changes, because after Andrei opened
>>  14866 <https://pharo.fogbugz.com/default.asp?14866> Integrate GTools
>> (which got integrated in 40475)
>>  I uploaded some changes for issue
>>  14608 <https://pharo.fogbugz.com/default.asp?14608>
>>  ClassTest>>#testClassRespectsPolymorphismWithTrait failing due to
>> Spotter methods
>>  I set the status to "Fix Review needed",
>>
>    but my changes are integrated in 40475 too!
>>
>
>  I think that in the current situation, it is actually a good idea. And
> yes, the integration does include all latest versions of GT-related
> packages.
>
>  Before changing to development, we required a stable release for the
> integration. That implied:
> 1. creating a stable release and
> 2. integrating it in the Pharo through a separate issue.
>
>  Yet, in GT we all work on the very latest version, and creating a
> "stable" release is somewhat artificial given the speed at which things are
> changing now. Creating the "stable" version also led to delays between a
> fix in GT and an integration in Pharo (sometimes measured in weeks). So, in
> the case of GT requiring the stable release did not provide any added
> value, but it has the negative consequence of delays.
>
>     I am not satisfied with the way external packages are handled.
>>  1. if there is not one slice/changeset per issue, it is even less
>> likely someone will
>>      review the changes.
>>  2. you don't know who works when on a issue. They are solved in a bulk.
>>  3. a new configuration might not only includes bugfixes but new
>> features as well.
>>  4. often we have unbound globals / undeclared references or other test
>> failures.
>>
>>  Can we use the build server for those external projects (like
>> GToolkitCore, Athens, TxText),
>> and that if a project makes a new configuration, it uses the same
>>  issue validator for loading and testing that configuration?
>>
>
>  We already have a GToollkitCore job, but it only runs the GT tests.
> Perhaps this is not enough?
> https://ci.inria.fr/moose/job/gtoolkitcore/
>
>  But, could the Monkey not be able to run all tests before an integration
> of the development version?
>
>  Cheers,
> Doru
>
>
>
>  --
>  www.tudorgirba.com
>
>  "Every thing has its own flow"
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Reply via email to