Interesting. Does Metacello allow us to associate #stable with a version of a platform (for instance, #stable for Moose 4.7)? Because #stable isn't always stable, as you have pointed out.
On Wed, Apr 17, 2013 at 8:34 AM, Diego Lont diego.lont@delware.nl wrote:
Problem found, thanks to Doru. It was loading the stable version of Glamour. That is apparently not stable in 4.8. It should load the development version. I changed this, and now I can continue working once I load GlamourSeaside. Running the tests failed 44 out of 66: When I browse through them I saw two problems: it needed a HTTPRequest, that no longer exists (problem in Seaside Tests), and I did not start the Parasol server. So no surprises here yet. Maybe someone else can test if GlamourSeaside loads good?
Cheers, Diego
P.S. I now loaded my configuration using GTMetaceller.
Thanks for doing this.
I am not sure what you mean by becoming unstable. ConfigurationOfGlamour #development is already loaded in the image. It should not cause any further problems.
What might happen is that ConfigurationOfGlamour loads Magritte which loads Grease, and this might have an impact on Seaside. Maybe we are not loading the proper versions. Could it be it?
Cheers, Doru
On Wed, Apr 17, 2013 at 4:01 PM, Diego Lont diego.lont@delware.nl wrote:
Hi all,
Done some more testing and cleaned to configuration to follow standards.
I have an additional note. Currently when I load the development version of ConfigurationOfGlamour into moose 4.8, my moose becomes unstable. I am not sure what is wrong here, but this makes it hard to test well. So I guess I am stuck untill Glamour is stable again in 4.8.
Serge and Doru,
Please let me know if some more work is needed on the ConfigurationOfGlamourSeaside. It should be fine now.
Cheers, Diego
Hi all,
I am not fully done testing, but so far looking good, so here I share
how far I am:
Version 0.4 is tested in Moose 4.8. I loaded it in Pharo 2.0 and got
an error while loading Seaside Tests. Only the tests depend on this project, so this should be ok. Maybe the tests even run, when you proceed on the warning.
Important note: the configuration of Seaside30 comes from Seaside30
repository instead of the MetacelloRepository on squeak source. So you need to load this configuration manually before loading GlamourSeaside.
After manually loading configuration of GlamourSeaside and Seaside30
the following should load this project:
(ConfigurationOfGlamourSeaside project version: '0.4') load: 'Examples' After that you should of course start the server by: ZnZincServerAdaptor startOn: 8080
Cheers
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Yes. In the symbolic version.
Should I make Glamour 2.4 the stable version for Pharo 2.0?
On Apr 17, 2013, at 7:36 PM, Chris Cunningham wrote:
Interesting. Does Metacello allow us to associate #stable with a version of a platform (for instance, #stable for Moose 4.7)? Because #stable isn't always stable, as you have pointed out.
I took a look at the ConfigurationOfGlamour and saw that 2.4 was already the stable version for Pharo 1.4.x, so I added this also for Pharo 2.x
Diego
On Apr 17, 2013, at 10:59 PM, Diego Lont wrote:
Yes. In the symbolic version.
Should I make Glamour 2.4 the stable version for Pharo 2.0?
On Apr 17, 2013, at 7:36 PM, Chris Cunningham wrote:
Interesting. Does Metacello allow us to associate #stable with a version of a platform (for instance, #stable for Moose 4.7)? Because #stable isn't always stable, as you have pointed out.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----- Original Message ----- | From: "Chris Cunningham" cunningham.cb@gmail.com | To: "Moose-related development" moose-dev@iam.unibe.ch | Sent: Wednesday, April 17, 2013 10:36:38 AM | Subject: [Moose-dev] #stable and Metacello (was Re: ConfigurationOfGlamourSeaside) | | Interesting. Does Metacello allow us to associate #stable with a version of a | platform (for instance, #stable for Moose 4.7)? Because #stable isn't always | stable, as you have pointed out.
Chris,
A symbolic version is basically a tag for a given attribute (#common, #squeak, #pharo2.x, etc.) and version (1.7, 3.5, 4.8, etc.).
#stable is a name that is used by convention to denote the version that _should_ be used on a particular platform, i.e., we could have used another name like #'recommended_version' or #'as_stable_as_it_gets'.
In practice, there is no guarantee that the release is actually stable on the given platform. The platform itself may not be stable ... or in this particular case it appears that the root cause was an instability in a dependent project ...
Metacello "allows" developers to declare attribute/version pairs as #stable in the same way that Squeak allows one to write code with bugs in it:) and as with Squeak, the bug isn't always in your own code...
When it comes to platform and dependency management one can have tight coupling and loose coupling ...
In systems that are under constant development tight coupling is completely impractical, because one must change all of the project configurations for projects that depend upon your project when you make a bugfix release. With lots of projects undergoing constant bugfixing this can quickly turn into a nightmare.
Using symbolic versions gives a bit of wiggle room. When you make a bugfix release, you can declare that the new version is #stable and any projects that depend upon your project will automatically pick up your bugfix ...
Unfortunately, the additional wiggle room means that I can make what I consider a bugfix release and _introduce_ bugs in a project that depends upon my project ....
The only defense against this is to use tight coupling which may hinder progress ...
So in the end developers must make a decision as to which direction they want to go ... and Metacello gives the developers the freedom to make that choice...
Dale
Dale, Thank you for the response. So the simple answer to my question is 'yes, it is supported'. The longer answer is Yes, depending how you want to use it.
On Wed, Apr 17, 2013 at 2:21 PM, Dale Henrichs dhenrich@vmware.com wrote:
----- Original Message ----- | From: "Chris Cunningham" cunningham.cb@gmail.com | To: "Moose-related development" moose-dev@iam.unibe.ch | Sent: Wednesday, April 17, 2013 10:36:38 AM | Subject: [Moose-dev] #stable and Metacello (was Re: ConfigurationOfGlamourSeaside) | | Interesting. Does Metacello allow us to associate #stable with a version of a | platform (for instance, #stable for Moose 4.7)? Because #stable isn't always | stable, as you have pointed out.
Chris,
A symbolic version is basically a tag for a given attribute (#common, #squeak, #pharo2.x, etc.) and version (1.7, 3.5, 4.8, etc.).
#stable is a name that is used by convention to denote the version that _should_ be used on a particular platform, i.e., we could have used another name like #'recommended_version' or #'as_stable_as_it_gets'.
In practice, there is no guarantee that the release is actually stable on the given platform. The platform itself may not be stable ... or in this particular case it appears that the root cause was an instability in a dependent project ...
Metacello "allows" developers to declare attribute/version pairs as #stable in the same way that Squeak allows one to write code with bugs in it:) and as with Squeak, the bug isn't always in your own code...
When it comes to platform and dependency management one can have tight coupling and loose coupling ...
In systems that are under constant development tight coupling is completely impractical, because one must change all of the project configurations for projects that depend upon your project when you make a bugfix release. With lots of projects undergoing constant bugfixing this can quickly turn into a nightmare.
Using symbolic versions gives a bit of wiggle room. When you make a bugfix release, you can declare that the new version is #stable and any projects that depend upon your project will automatically pick up your bugfix ...
Unfortunately, the additional wiggle room means that I can make what I consider a bugfix release and _introduce_ bugs in a project that depends upon my project ....
The only defense against this is to use tight coupling which may hinder progress ...
So in the end developers must make a decision as to which direction they want to go ... and Metacello gives the developers the freedom to make that choice...
Dale _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Dale
I thought that stable should be called milestoneDevelopment. I will add a note to the metacello chapter and versionner will handle the patterns we see.
Stef
On Apr 17, 2013, at 11:21 PM, Dale Henrichs dhenrich@vmware.com wrote:
----- Original Message ----- | From: "Chris Cunningham" cunningham.cb@gmail.com | To: "Moose-related development" moose-dev@iam.unibe.ch | Sent: Wednesday, April 17, 2013 10:36:38 AM | Subject: [Moose-dev] #stable and Metacello (was Re: ConfigurationOfGlamourSeaside) | | Interesting. Does Metacello allow us to associate #stable with a version of a | platform (for instance, #stable for Moose 4.7)? Because #stable isn't always | stable, as you have pointed out.
Chris,
A symbolic version is basically a tag for a given attribute (#common, #squeak, #pharo2.x, etc.) and version (1.7, 3.5, 4.8, etc.).
#stable is a name that is used by convention to denote the version that _should_ be used on a particular platform, i.e., we could have used another name like #'recommended_version' or #'as_stable_as_it_gets'.
In practice, there is no guarantee that the release is actually stable on the given platform. The platform itself may not be stable ... or in this particular case it appears that the root cause was an instability in a dependent project ...
Metacello "allows" developers to declare attribute/version pairs as #stable in the same way that Squeak allows one to write code with bugs in it:) and as with Squeak, the bug isn't always in your own code...
When it comes to platform and dependency management one can have tight coupling and loose coupling ...
In systems that are under constant development tight coupling is completely impractical, because one must change all of the project configurations for projects that depend upon your project when you make a bugfix release. With lots of projects undergoing constant bugfixing this can quickly turn into a nightmare.
Using symbolic versions gives a bit of wiggle room. When you make a bugfix release, you can declare that the new version is #stable and any projects that depend upon your project will automatically pick up your bugfix ...
Unfortunately, the additional wiggle room means that I can make what I consider a bugfix release and _introduce_ bugs in a project that depends upon my project ....
The only defense against this is to use tight coupling which may hinder progress ...
So in the end developers must make a decision as to which direction they want to go ... and Metacello gives the developers the freedom to make that choice...
Dale _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Stef,
I think it is clear that #stable is not the right name, but I also think it is better to have one "badly named," commonly used symbolic version rather than a bunch of different names for the same thing... Eventually we should change the convention, but I don't think we need to hurry and do so:)
Dale
----- Original Message ----- | From: "stephane ducasse" stephane.ducasse@free.fr | To: "Moose-related development" moose-dev@iam.unibe.ch | Sent: Wednesday, April 17, 2013 10:04:50 PM | Subject: [Moose-dev] Re: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside) | | Dale | | I thought that stable should be called milestoneDevelopment. | I will add a note to the metacello chapter and versionner will handle the | patterns we see. | | Stef | | On Apr 17, 2013, at 11:21 PM, Dale Henrichs dhenrich@vmware.com wrote: | | > | > | > ----- Original Message ----- | > | From: "Chris Cunningham" cunningham.cb@gmail.com | > | To: "Moose-related development" moose-dev@iam.unibe.ch | > | Sent: Wednesday, April 17, 2013 10:36:38 AM | > | Subject: [Moose-dev] #stable and Metacello (was Re: | > | ConfigurationOfGlamourSeaside) | > | | > | Interesting. Does Metacello allow us to associate #stable with a version | > | of a | > | platform (for instance, #stable for Moose 4.7)? Because #stable isn't | > | always | > | stable, as you have pointed out. | > | > Chris, | > | > A symbolic version is basically a tag for a given attribute (#common, | > #squeak, #pharo2.x, etc.) and version (1.7, 3.5, 4.8, etc.). | > | > #stable is a name that is used by convention to denote the version that | > _should_ be used on a particular platform, i.e., we could have used | > another name like #'recommended_version' or #'as_stable_as_it_gets'. | > | > In practice, there is no guarantee that the release is actually stable on | > the given platform. The platform itself may not be stable ... or in this | > particular case it appears that the root cause was an instability in a | > dependent project ... | > | > Metacello "allows" developers to declare attribute/version pairs as #stable | > in the same way that Squeak allows one to write code with bugs in it:) and | > as with Squeak, the bug isn't always in your own code... | > | > When it comes to platform and dependency management one can have tight | > coupling and loose coupling ... | > | > In systems that are under constant development tight coupling is completely | > impractical, because one must change all of the project configurations for | > projects that depend upon your project when you make a bugfix release. | > With lots of projects undergoing constant bugfixing this can quickly turn | > into a nightmare. | > | > Using symbolic versions gives a bit of wiggle room. When you make a bugfix | > release, you can declare that the new version is #stable and any projects | > that depend upon your project will automatically pick up your bugfix ... | > | > Unfortunately, the additional wiggle room means that I can make what I | > consider a bugfix release and _introduce_ bugs in a project that depends | > upon my project .... | > | > The only defense against this is to use tight coupling which may hinder | > progress ... | > | > So in the end developers must make a decision as to which direction they | > want to go ... and Metacello gives the developers the freedom to make that | > choice... | > | > Dale | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On Apr 18, 2013, at 6:29 PM, Dale Henrichs dhenrich@vmware.com wrote:
Stef,
I think it is clear that #stable is not the right name, but I also think it is better to have one "badly named," commonly used symbolic version rather than a bunch of different names for the same thing…
yes but this can be confusing.
Eventually we should change the convention, but I don't think we need to hurry and do so:)
first we need a tool to manage configuration for real.
Stef
Dale
----- Original Message ----- | From: "stephane ducasse" stephane.ducasse@free.fr | To: "Moose-related development" moose-dev@iam.unibe.ch | Sent: Wednesday, April 17, 2013 10:04:50 PM | Subject: [Moose-dev] Re: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside) | | Dale | | I thought that stable should be called milestoneDevelopment. | I will add a note to the metacello chapter and versionner will handle the | patterns we see. | | Stef | | On Apr 17, 2013, at 11:21 PM, Dale Henrichs dhenrich@vmware.com wrote: | | > | > | > ----- Original Message ----- | > | From: "Chris Cunningham" cunningham.cb@gmail.com | > | To: "Moose-related development" moose-dev@iam.unibe.ch | > | Sent: Wednesday, April 17, 2013 10:36:38 AM | > | Subject: [Moose-dev] #stable and Metacello (was Re: | > | ConfigurationOfGlamourSeaside) | > | | > | Interesting. Does Metacello allow us to associate #stable with a version | > | of a | > | platform (for instance, #stable for Moose 4.7)? Because #stable isn't | > | always | > | stable, as you have pointed out. | > | > Chris, | > | > A symbolic version is basically a tag for a given attribute (#common, | > #squeak, #pharo2.x, etc.) and version (1.7, 3.5, 4.8, etc.). | > | > #stable is a name that is used by convention to denote the version that | > _should_ be used on a particular platform, i.e., we could have used | > another name like #'recommended_version' or #'as_stable_as_it_gets'. | > | > In practice, there is no guarantee that the release is actually stable on | > the given platform. The platform itself may not be stable ... or in this | > particular case it appears that the root cause was an instability in a | > dependent project ... | > | > Metacello "allows" developers to declare attribute/version pairs as #stable | > in the same way that Squeak allows one to write code with bugs in it:) and | > as with Squeak, the bug isn't always in your own code... | > | > When it comes to platform and dependency management one can have tight | > coupling and loose coupling ... | > | > In systems that are under constant development tight coupling is completely | > impractical, because one must change all of the project configurations for | > projects that depend upon your project when you make a bugfix release. | > With lots of projects undergoing constant bugfixing this can quickly turn | > into a nightmare. | > | > Using symbolic versions gives a bit of wiggle room. When you make a bugfix | > release, you can declare that the new version is #stable and any projects | > that depend upon your project will automatically pick up your bugfix ... | > | > Unfortunately, the additional wiggle room means that I can make what I | > consider a bugfix release and _introduce_ bugs in a project that depends | > upon my project .... | > | > The only defense against this is to use tight coupling which may hinder | > progress ... | > | > So in the end developers must make a decision as to which direction they | > want to go ... and Metacello gives the developers the freedom to make that | > choice... | > | > Dale | > _______________________________________________ | > Moose-dev mailing list | > Moose-dev@iam.unibe.ch | > https://www.iam.unibe.ch/mailman/listinfo/moose-dev | | | _______________________________________________ | Moose-dev mailing list | Moose-dev@iam.unibe.ch | https://www.iam.unibe.ch/mailman/listinfo/moose-dev | _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Chris Cunningham -
Dale Henrichs -
Diego Lont -
stephane ducasse