On Apr 18, 2013, at 6:29 PM, Dale Henrichs <dhenrich(a)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(a)free.fr>
| To: "Moose-related development" <moose-dev(a)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(a)vmware.com> wrote:
|
| >
| >
| > ----- Original Message -----
| > | From: "Chris Cunningham" <cunningham.cb(a)gmail.com>
| > | To: "Moose-related development" <moose-dev(a)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(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