Hi,
Perhaps something was not clear.
I did not say that everyone should work on the latest Moose. We go through
the (painful) trouble of creating stable versions exactly because we want
to offer the alternative of depending on something that does not change.
But, if someone wants support this will be provided on the latest Moose
because this is where the development activity is. This will happen on the
latest Pharo because especially now that GT is adopted in Pharo, the
development effort is too close to be practical to support two different
branches. Before Moose 5.0 we tried for a while to maintain GT for both
Pharo 3 and deal with changes in Pharo 4 and we do not want to go through
this again. This might change if the tool support changes.
Now, if someone wants to backport changes to an older Moose version, we can
put in place a separate repository that can host those backported changes.
Cheers,
Tudor
On Mon, May 11, 2015 at 4:22 PM, Nicolas Anquetil <nicolas.anquetil(a)inria.fr
wrote:
>
> Just to explain,
>
> we try to make a living by building on top of Moose
> we try to adapt it to the lambda Cobol developper that may not be
> interested in learning a new syntax
>
> So the simplest change in Moose can sometimes break everything for us.
> As Usman explained, we cannot test again each morning every single feature
> we already implemented for every language we support.
>
> So having a bleeding edge Moose for us is not a solution
>
> nicolas
>
>
> On 11/05/2015 11:12, Usman Bhatti wrote:
>
> Hi,
>
> In Synectique's case, we had several problems working with Bleeding edge
> of Moose:
>
> 1/ changes to the API
> 2/ changes that lead to performance problems
> 3/ when depending on bleeding edge of Pharo always testing the combo Pharo
> + Moose
>
> The first one is important because one does not want to spend resources
> adapting to inadvertent changes. And it is easy to handle as one can always
> depend on a given version number (not a stable because it is moving and may
> create surprises that are less frequent than the bleeding edge).
>
> Regarding changes that lead to performance issues, someone must test
> with real cases and evaluate. Depending on the version number works fine
> here too.
>
> We would not have needed to create our own configuration if we could
> downgrade PetitParser but apparently, that is not possible and hence the
> easier solution was to create our own configuration.
>
> The ConfigurationOfSynectiqueMoose is just an assembly of existing
> versions of the components in Moose (these versions are published
> publicly). We just loading by hand:
> -> SmallDude because it has a dependency on ConfigurationOfMoose
> -> GT-Toolkit and PetitSQL because there were paths leading to PetitParser
> #development.
>
> As for Moose depending on the bleeding edge of Pharo, it is risky
> business because when demoing or delivering a new version to a client, the
> red square of death is difficult to justify. With the stable version, we at
> least know where not to click :p. But one is not testing new combinations
> (coming from Pharo + Moose) in production.
>
> But if there are alternate solutions in our eco-system that enable the
> use of bleeding edge in production that shield the users from inadvertent
> changes, it'll be nice to know.
>
> regards,
>
> Usman
>
>
>
>
>
>
> On Thu, May 7, 2015 at 11:03 PM, Tudor Girba <tudor(a)tudorgirba.com
wrote:
>
>> Hi,
>>
>> Yes, I think we have a different point of view on what Moose is.
>>
>> I do not expect people to fork, but if they do, I would expect them to
>> do it in a public place and help us maintain the configuration(s). For
>> example, we could have:
>> - a Moose/Moose51 repository
>> - commit packages with new patches for Moose 5.1 only there, and
>> - modify the #stable version corresponding configurations to load those
>> new packages.
>>
>> This is doable. Would that be Ok?
>>
>> Cheers,
>> Doru
>>
>>
>>
>>
>>
>> On Wed, May 6, 2015 at 9:43 PM, stepharo <stepharo(a)free.fr
wrote:
>>
>>> Just a question.
>>> Do you expect people needing to have stable version to fork and work in
>>> their corners?
>>> I do not get why Moose dev should systematically be under the bleeding
>>> edge of Pharo.
>>> I probably do not understand what Moose is.
>>>
>>> Stef
>>>
>>> Le 5/5/15 19:17, Tudor Girba a écrit :
>>>
>>> Please do not do this until we release. The reason is that this will
>>> generate more commits that will be specific to pharo 5, like the current
>>> substring problem in get inspector.
>>>
>>> The goal is to release this or next week, and then we move to pharo 5.
>>>
>>> Cheers,
>>> Doru
>>>
>>> --
>>>
www.tudorgirba.com
>>>
>>> "Every thing has its own flow"
>>>
>>> On 05 May 2015, at 19:52, Alexandre Bergel <alexandre.bergel(a)me.com>
>>
wrote:
>>>
>>> Anyone who has access to the CI can do this?
>>>
>>> Alexandre
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel
http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>> On May 5, 2015, at 8:59 AM, Andrei Chis <chisvasileandrei(a)gmail.com>
>>
wrote:
>>>
>>> Hi Alexandre,
>>>
>>> Right now now we're updating configurations and fixing the remaining
>>> issues to be able to release moose 5.1
>>> We can in parallel start a build for Pharo 5 but we do not have to
>>> much time to invest in it (apart from starting it) until we release.
>>>
>>> Cheers,
>>> Andrei
>>>
>>> On Tue, May 5, 2015 at 3:52 PM, Alexandre Bergel <
>>> alexandre.bergel(a)me.com
wrote:
>>>
>>>> Hi!
>>>>
>>>> Is there any plan to move on Pharo 5?
>>>> Can someone trigger a build?
>>>>
>>>> Cheers,
>>>> Alexandre
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel
http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>>
>>
>>
>> --
>>
www.tudorgirba.com
>>
>> "Every thing has its own flow"
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>>
>
>
> _______________________________________________
> Moose-dev mailing
listMoose-dev@iam.unibe.chhttps://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
>
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
--
www.tudorgirba.com
"Every thing has its own flow"