#stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
Locked
 
|
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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] 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. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
|
|
In reply to this post by cbc
----- Original Message ----- | From: "Chris Cunningham" <[hidden email]> | To: "Moose-related development" <[hidden email]> | 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
|
|
In reply to this post by Dale Henrichs
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 <[hidden email]> wrote: > > > ----- Original Message ----- > | From: "Chris Cunningham" <[hidden email]> > | To: "Moose-related development" <[hidden email]> > | 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 > [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 |
|
|
In reply to this post by DiegoLont
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 > [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 |
Re: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
|
|
In reply to this post by stephane ducasse
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" <[hidden email]> | To: "Moose-related development" <[hidden email]> | 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 <[hidden email]> wrote: | | > | > | > ----- Original Message ----- | > | From: "Chris Cunningham" <[hidden email]> | > | To: "Moose-related development" <[hidden email]> | > | 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 | > [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 | _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Re: #stable and Metacello (was Re: ConfigurationOfGlamourSeaside)
|
|
On Apr 18, 2013, at 6:29 PM, Dale Henrichs <[hidden email]> 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" <[hidden email]> > | To: "Moose-related development" <[hidden email]> > | 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 <[hidden email]> wrote: > | > | > > | > > | > ----- Original Message ----- > | > | From: "Chris Cunningham" <[hidden email]> > | > | To: "Moose-related development" <[hidden email]> > | > | 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 > | > [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 > | > _______________________________________________ > 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 |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |