to have a default select: [:each | 'pac*' match
and to avoid to have ' in drop box and this is not in the latest version of moose. How do we know merge process work in moose?
Stef
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
We udpated the configuration of merlin
So that satble in 1.5 and development is 1.6 and 1.6 contains our changes On Tue, Nov 8, 2011 at 6:33 PM, Usman Bhatti <[hidden email]> wrote: to have a default select: [:each | 'pac*' match _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
This is precisely the problem I was referring to when I said that it is not clear what is the best solution when versioning Moose with Metacello. What we do not want is lose versions like this along the way.
Cheers, Doru On 8 Nov 2011, at 19:08, Usman Bhatti wrote: > We udpated the configuration of merlin > > So that satble in 1.5 and development is 1.6 and 1.6 contains our changes > > > On Tue, Nov 8, 2011 at 6:33 PM, Usman Bhatti <[hidden email]> wrote: > to have a default select: [:each | 'pac*' match > > and to avoid to have ' in drop box and this is not in the latest version of moose. > > How do we know merge process work in moose? > > Stef > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Beauty is where we see it." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
we do not lose anything if we have a clear process.
Right now I have no idea what is the process. And just publishing a package and thinking that it will be loaded leads to the fact that we cannot load moose anymore. There is nothing like a free lunch and we could script metacello to generate support our process. It makes me smile because we say that we are tool builder and we still do not script the API of metacello. Stef > This is precisely the problem I was referring to when I said that it is not clear what is the best solution when versioning Moose with Metacello. What we do not want is lose versions like this along the way. > > Cheers, > Doru > > > On 8 Nov 2011, at 19:08, Usman Bhatti wrote: > >> We udpated the configuration of merlin >> >> So that satble in 1.5 and development is 1.6 and 1.6 contains our changes >> >> >> On Tue, Nov 8, 2011 at 6:33 PM, Usman Bhatti <[hidden email]> wrote: >> to have a default select: [:each | 'pac*' match >> >> and to avoid to have ' in drop box and this is not in the latest version of moose. >> >> How do we know merge process work in moose? >> >> Stef >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi,
On 13 Nov 2011, at 09:02, Stéphane Ducasse wrote: > we do not lose anything if we have a clear process. > Right now I have no idea what is the process. > And just publishing a package and thinking that it will be loaded leads to the fact that we cannot load moose anymore. This is because of the mess introduced by having hardcoded versions during development. > There is nothing like a free lunch and we could script metacello to generate support our process. > It makes me smile because we say that we are tool builder and we still do not script the API of metacello. You wrote a chapter on Metacello. So, you are a great candidate for providing the support :). Cheers, Doru > Stef > > >> This is precisely the problem I was referring to when I said that it is not clear what is the best solution when versioning Moose with Metacello. What we do not want is lose versions like this along the way. >> >> Cheers, >> Doru >> >> >> On 8 Nov 2011, at 19:08, Usman Bhatti wrote: >> >>> We udpated the configuration of merlin >>> >>> So that satble in 1.5 and development is 1.6 and 1.6 contains our changes >>> >>> >>> On Tue, Nov 8, 2011 at 6:33 PM, Usman Bhatti <[hidden email]> wrote: >>> to have a default select: [:each | 'pac*' match >>> >>> and to avoid to have ' in drop box and this is not in the latest version of moose. >>> >>> How do we know merge process work in moose? >>> >>> Stef >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Beauty is where we see it." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "When people care, great things can happen." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
> Hi,
> > On 13 Nov 2011, at 09:02, Stéphane Ducasse wrote: > >> we do not lose anything if we have a clear process. >> Right now I have no idea what is the process. >> And just publishing a package and thinking that it will be loaded leads to the fact that we cannot load moose anymore. > > This is because of the mess introduced by having hardcoded versions during development. > >> There is nothing like a free lunch and we could script metacello to generate support our process. >> It makes me smile because we say that we are tool builder and we still do not script the API of metacello. > > You wrote a chapter on Metacello. So, you are a great candidate for providing the support :). sure! Now you will probably not like the result. I still do not understand what was wrong with putting versions. I wonder why I wrote it since nobody reads it. I will fork the ConfigurationOf and see but I have no time for that now. Stef _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On 13 Nov 2011, at 22:05, Stéphane Ducasse wrote: >> Hi, >> >> On 13 Nov 2011, at 09:02, Stéphane Ducasse wrote: >> >>> we do not lose anything if we have a clear process. >>> Right now I have no idea what is the process. >>> And just publishing a package and thinking that it will be loaded leads to the fact that we cannot load moose anymore. >> >> This is because of the mess introduced by having hardcoded versions during development. >> >>> There is nothing like a free lunch and we could script metacello to generate support our process. >>> It makes me smile because we say that we are tool builder and we still do not script the API of metacello. >> >> You wrote a chapter on Metacello. So, you are a great candidate for providing the support :). > > sure! It was a joke :) > Now you will probably not like the result. I still do not understand what was wrong with putting versions. Nothing. Just doing it manually was too error prone and I could not keep up with it. And for development, I want to continue to push for the last version of all packages. The thing that would work well with our process is to produce a configuration for what is in the image at some moment. But, it is difficult to produce with nested configurations. So, in the meantime we should traverse the Configuration and produce a simple flat Gofer script. This could be a nice bridge solution. > I wonder why I wrote it since nobody reads it. > > I will fork the ConfigurationOf and see but I have no time for that now. Do not fork it :). Just add publish on top. Doru > Stef > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "There are no old things, there are only old ways of looking at them." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
>>
> > It was a joke :) Well my plate is so full in this moment. BTW I worked on the metacello chapter and I made progress. I hope to have review fully soon. > >> Now you will probably not like the result. I still do not understand what was wrong with putting versions. > > Nothing. Just doing it manually was too error prone and I could not keep up with it. And for development, I want to continue to push for the last version of all packages. Yes so why don't you read the chapter and see. > The thing that would work well with our process is to produce a configuration for what is in the image at some moment. But, it is difficult to produce with nested configurations. So, in the meantime we should traverse the Configuration and produce a simple flat Gofer script. This could be a nice bridge solution. ok I see >> I wonder why I wrote it since nobody reads it. >> >> I will fork the ConfigurationOf and see but I have no time for that now. > > Do not fork it :). Just add publish on top. what does it mean? Because if we start to freeze the versions then getting the last version will get more difficult. > > Doru > >> Stef >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "There are no old things, there are only old ways of looking at them." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi,
>>> I will fork the ConfigurationOf and see but I have no time for that now. >> >> Do not fork it :). Just add publish on top. > > what does it mean? > Because if we start to freeze the versions then getting the last version will get more difficult. Having fixed versions will not interfere with having a baseline that will be loaded by Jenkins. The idea is that versions will not be essential for our development. They will only offer the possibility to load past versions. Cheers, Doru _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Ok I see
so you load baseline and we snapshot version. Stef On Nov 14, 2011, at 7:51 AM, Tudor Girba wrote: > Hi, > >>>> I will fork the ConfigurationOf and see but I have no time for that now. >>> >>> Do not fork it :). Just add publish on top. >> >> what does it mean? >> Because if we start to freeze the versions then getting the last version will get more difficult. > > Having fixed versions will not interfere with having a baseline that will be loaded by Jenkins. The idea is that versions will not be essential for our development. They will only offer the possibility to load past versions. > > Cheers, > Doru > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Precisely.
Doru On Mon, Nov 14, 2011 at 10:49 AM, Stéphane Ducasse <[hidden email]> wrote: Ok I see "Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |