the future of #stable in Metacello

I've cross-posted to pharo and metacello mailing list ... I'd prefer that the ongoing (possibly gory discussion:) take place on the metacello list, but since symbolic versions have been discussed on the pharo list it might make sense to keep the discussion in the pharo list ...

First a bit of background.

Symbolic versions were introduced because we were facing a situation where developers were breaking projects that were working fine in Pharo1.3 while porting them to Pharo1.4 and breaking Pharo1.4 behavior while fixing bugs in Pharo1.3 ...

Metacello was pretty new then and an attempt was being made to have folks use Pharo1.4 while it was still in development and there were enough changes in Pharo1.4 that some code would break in Pharo1.4 while working in Pharo1.3 ... The real problem though was that project dependencies became difficult to manage in a number of different dimensions:

  - projects would change existing versions to work on
    the new platform version and break the old platform
    version
  - projects would create a new version that would run on
    both platforms, so dependent projects would to depend
    pon a new version
  - projects would create a new version that would run on
    only one platform, so dependent projects would have to
    depend upon 2 different versions based on platform
    version

These types of things in isolation would be manageable, but the rate of change was high and changes propogated faster than configuration managers could keep up with. Oh and don't forget the projects where the maintainers were not even using Metacello at all and a third party developer had to translate the projects changes to a configuration to keep things working...

Symbolic versions were introduced as a stopgap measure that made it possible for folks to easily declare which versions of the project were intended to be used on a particular platform. Dependent projects could depend upon the #stable version and the whole dependency management universe became simpler. Symbolic versions made it practical to port code to Pharo1.4 without impacting Pharo1.3 and so on.

Which brings us to the present and a slightly different situation, but first let's step back a bit and look at what we have in Metacello today.

In Metacello, a version is a label applied to a specific collection of mcz files. The collection of mcz files may be different depending upon which platform you happen to be loading the project into, but in the end, the same version on different platforms should give one the same set of functionality.

Once a version has been released (indicated by a #release blessing) the contents of that collection of mcz files should never change ... If a change _is_ made, once should create a new version of the project to reflect that something has changed.

In Metacello there are platform attributes (i.e., #'pharo1.x', #'pharo1.4.x', #'pharo1.4.1.x', #'pharo2.x', etc.). The platform attributes can provide very fine-grained control over which mcz files need to be loaded into a particular version of a platform, but the mechanism only works if the underlying platform is consistently naming versions ...

In Metacello symbolic versions are simply a tagging mechanism. Versions and symbolic versions can be used interchangeably. Any name/platform/version combination can be created.

We have been using the #stable convention for several years and it is definitely time to revisit it's use. However, we cannot drop the #stable convention without replacing it with another convention... otherwise we risk chaos, again:)

In Metacello one can specify dependencies in terms of specific version numbers (tight coupling) or a tag (very loose coupling). Allowing one to specify dependencies based on version ranges would provide an intermediate coupling that avoids the tight coupling of specific version numbers while avoiding the ambiguity of a convention based on the name of a tag (symbolic version).

If we introduce version range dependencies then individual projects can use a variety symbolic version names to properly represent their desired semantics.

If we introduce version range dependencies then we must adopt a convention for how versions are named and that convention must be used pretty consistently within the community otherwise we may just have to return to the world of using #stable in self defense again ...

As an alternative to a version numbering convention like Semantic Versioning[1], we could adopt a convention defining the semantics of a collection of symbolic version names ....

I am a fan of Semantic Versioning, but it has some pretty specific rules that "must" be followed and all projects including the Smalltalk platforms (GemStone, Pharo and Squeak). Scan through the discussions surrounding Semantic Versions[2] to see what I'm talking about...

In the grand scheme of things I don't want Metacello to be locked into any one convention. I am willing to have Metacello to support multiple conventions if called for.

I have support for the Semantic Versioning version numbering scheme in Metacello, but other schemes can be added. I have anticipated the need to support version number ranges and have already built in a certain level of support and am willing to expand the capabilities in this area as needed ...

Whatever the convention is, it has to be ADOPTED and SUPPORTED by the community. Metacello cannot enforce conventions, it can only support conventions ...

So in closing, I would say that the future of #stable is in your hands...

Dale

[1] http://semver.org/
[2] https://github.com/mojombo/semver/issues

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

I believe that if the Metacello world were to migrate to using Semantic
Versioning, a lot of things would vastly improve.

I've been engaged at a client who uses both GemStone and Pharo to
upgrade their dependencies on third party systems such as Seaside,
Grease, Magritte, and so on, and I must say, down in the trenches, the
state of the art in Smalltalk packaging seems to be "dependency hell".

The norm seems to be for, say, Foo to depend on Bar-UI-xyz.101.mcz and
Baz-Core-abc.102.mcz, while Baz-Core in turn depends on
Bar-UI-xyz.102.mcz.

Metacello will, heroically, apply some heuristics to try and get the
resuling system loaded by for example first loading Bar-UI-xyz.101.mcz
and then later loading Bar-UI-xyz.102.mcz as needed.

And everytime I see situations like that I cross my fingers and think:
"sheesh, I hope there were no backwards-incompatible changes between
Bar-UI-xyz.101.mcz and Bar-UI-xyz.102.mcz, because if any slip through
testing, the client is going to blame me".

But, frankly, this is wrong. Metacello's role should be to take
packagers at their word and very strictly apply what they say. If the
packagers "lie" and give a stricter dependency than what they intend to,
my feeling is: tough cookies - let them learn to specify their
dependencies correctly.

And the only correct way to specify those dependencies would be for Foo
to say "I depend on Bar-UI >= 10.3.1 and < 11", and for Baz to say "I
depend on Bar-UI >= 10.3.2 < 11". That way, Monticello at least has a
hope to determine that the entire collection of packages will indeed
have their dependencies satisfied by Bar-UI 10.3.2, so I'll load that,
and only that, once.

I would like a world where:

1. Semantic versioning, in the sense of depending on range of versions
that are intended to be compatible, becomes the norm, the easiest to
express in Metacello's API, and the only thing one sees on "how to use
Metacello" docs.

2. Depending on specific versions such as Bar-UI-xyz.101.mcz be
absolutely disallowed by Metacello - with the only exception that
ConfigurationOfBar is allowed to tie a specific version of the Bar
project to specific mcz.that provide, say, Bar-UI and Bar-Core and the
like.

3. Before Metacello loads a set of dependencies, it walks the transitive
closure of all dependencies and just flat our refuse to load in cases
where one package needs Bar version X and another needs Bar version Y.
This will place pressure on the authors of the respective
ConfigurationOf... classes, to write their packages with sane
dependencies  on a range of versions . If you wrongly say that your
package only works with Bar version 10.1.2 instead of saying it works
with Bar version >= 10.1.2 and < 11, well, then that's your fault, not
Metacello's fault.

4. Metacello itself seems to contain a lot of complexity that seems to
be designed as a workaround for the fact that the community does not use
semantic versioning. The new scripting API, onUpgrade: hooks and the
like seem to be at least partially motivated by a desire for the user to
be able to say "You know, that package over there wants A-12345.mcz, but
I happen to hope that A-12346.mcz should work too, so let me add this
hook to override what the packagers said". I think the desires and
use-cases for feature like these would vastly reduce if, instead, the
upstream packagers would just do sane, semantic, versioning!

5. The actual version number of a package one is using and has loaded is
"in your face:. I've spent the past few months downloading
foo-dkh.651.mcz files and whatnot, but it is very rare when one can
easily determine "oh, what i've got hold of here is version 3.0.4 of the
foo project". My impresssion is that a lot of the projects don't really
care what their version numbers are; and if they don't care, how can the
users take care to know what version ranges they depend on?

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

On 23 April 2013 21:04, Pieter Nagel <[hidden email]> wrote:
Why? These correspond precisely to git commit IDs or svn revision IDs.
A version tag, semantic or otherwise, is just a label applied to one
of these.

Ah. No, you're saying that you should only declare dependencies on a
library - Bar 1.1, say - rather than parts of a library. It's _Bar's_
responsibility to say "version 1.1 uses Bar-UI-xyz.101.mcz", right?
(This doesn't matter for single-package libraries, mind you.)

> 3. Before Metacello loads a set of dependencies, it walks the transitive
> closure of all dependencies and just flat our refuse to load in cases
> where one package needs Bar version X and another needs Bar version Y.
> This will place pressure on the authors of the respective
> ConfigurationOf... classes, to write their packages with sane
> dependencies  on a range of versions . If you wrongly say that your
> package only works with Bar version 10.1.2 instead of saying it works
> with Bar version >= 10.1.2 and < 11, well, then that's your fault, not
> Metacello's fault.

With today's tech, I agree. There are other possibilities, but they
require a lot more work. Newspeak allows side-by-side loading of
modules. Squeak 4.5's Environments could well supply a similar ability
to, in one Environment Ex, load Bar version X and in another
Environment Ey load Bar version Y. Ex and Ey can export their
definitions without exposing which version of Bar they use.

Do you mean that you want metadata allowing you to take an image and
know what version of what package you have installed? (Kind've like a
dynamically generate Gemfile.lock.)

frank

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

On Tue, 2013-04-23 at 22:51 +0100, Frank Shearar wrote:
> On 23 April 2013 21:04, Pieter Nagel <[hidden email]> wrote:

> > 2. Depending on specific versions such as Bar-UI-xyz.101.mcz be
> > absolutely disallowed by Metacello - with the only exception that
> > ConfigurationOfBar is allowed to tie a specific version of the Bar
> > project to specific mcz.that provide, say, Bar-UI and Bar-Core and the
> > like.
>
> Why? These correspond precisely to git commit IDs or svn revision IDs.
> A version tag, semantic or otherwise, is just a label applied to one
> of these.

If a project Foo depends on a specific, SINGLE version of Bar, then that
 means that Foo is making massive assumptions about every other package
installed alongside it in the same image.

It either presumes that:

1) Nobody else is going to depend on Bar, and so it does not need to
take into account whether their version of Bar will satisfy other
packages too,

or 2) That everybody else who is going to use Bar will be happy with the
exact same single version that Foo is using.

In practice, this is unworkable. In the real world, people all kinds of
other packages of the shelf at Squeaksource, packages that the author of
Foo did not even know existed. And in the real world, those packages,
under the hood, then also depend on Grease, or XML-Writer, or whatever -
but some other, different version of that package.

In the real world (without some sort of semantic versioning), you end up
with dozens of packages, each of which depends on a different version of
something. And Metacello can only satisfy ONE of those dependencies, at
most. For everyone one of the rest, its a matter of crossing your
fingers and hoping that the packages will still work even though the got
a slightly different XML-Writer (for example) than they declared a
dependency on.

The core of the issue here is that depending on a SINGLE version of
somebody else's code is a no-no. Whether that dependency is declared on
a Monticello package name, Git commit SHA id, or tag tied to a specific
commit, or a symbolic version number "3.0.4.1-beta2", is implementation
detail.

The only sane way for packages to coexist in an ecosystem of other
packages, is for them to depend on a RANGE of versions, say >= 3.4.1 and
< 4, just for example. Then at least the packaging system has a hope of
finding a version that satisfies everybody.

The flip side of this, of course, is that whoever assigns a version
number to the packages they release, must also behave predictably, and
not break backwards compatibility unless they also bump their major
version number.

The semantic versioning spec that Dale linked to is one way to achieve
that.

> Ah. No, you're saying that you should only declare dependencies on a
> library - Bar 1.1, say - rather than parts of a library. It's _Bar's_
> responsibility to say "version 1.1 uses Bar-UI-xyz.101.mcz", right?
> (This doesn't matter for single-package libraries, mind you.)

Right. Firstly, because, as I said, depending on a specific SINGLE
version of any one thing can fundamentally just not work in an ecosystem
(unless that "thing" is an implementation detail purely under your
control that no one else will refer to).

And Monticello packages have only a SINGLE name, i.e.
Bar-UI-xyz.101.mcz. It is Metacello that assigns version numbers, and
that's the arena where semantic versioning can hopefully play out.

Secondly, because when other people go and declare dependencies on small
slices of other libraries implementation details, then they take
responsibility on their shoulders for getting that part's dependencies
right. And at best, that is duplicate, redundant code. At worst, you'll
get it wrong.

I think practices like these are just a recipe for dependency hell.

> With today's tech, I agree. There are other possibilities, but they
> require a lot more work. Newspeak allows side-by-side loading of
> modules. Squeak 4.5's Environments could well supply a similar ability
> to, in one Environment Ex, load Bar version X and in another
> Environment Ey load Bar version Y. Ex and Ey can export their
> definitions without exposing which version of Bar they use.

But let's suppose this kind of facility is available, and Metacello can
make use of it on all the platforms it runs on.

Without semantic versioning, Metacello will have no hope of knowing
whether it really NEEDS to load a different XML-Reader for every package
that uses it, or whether the authors were just sloppy in declaring
dependencies on single versions instead of ranges. In practice, it will
end up loading loads of different versions of XML-Reader.

Now, a security bug is found in XML-Reader, and they make a minor patch
release. But if you go and load the bugfix, then NONE of the packages
will end up using it, because they each still depend on their own
specific versions of XML-Reader. No, you will have to wait for each and
every on of the other packages to release updates that declare a
dependency on a newer XML-Reader that includes this bugfix.

With semantic versioning, one package would have depended on XML-Reader
>= 3.4.1, another would have dependend on version >= 3.4.7, and when the
bugfix version 3.4.99 came along, one could load that and EVERYONE could
have used that,

> Do you mean that you want metadata allowing you to take an image and
> know what version of what package you have installed? (Kind've like a
> dynamically generate Gemfile.lock.)

No, I mean I want the version numbers to be visible and in your face.
For example, in the Monticello browser (at least for a ConfigurationOf
package).

At the moment, wherever you click, you only see numbers like
Bar-UI-JohnDoe.101.mcz which carry zero semantic version info. If you
wnat the version number, you have to go call the Metacello API and query
it for what is loaded.

No wonder the de-facto practice is for people to just declare
dependencies on Bar-UI-JohnDoe.101.mcz instead of on a range of versions
of the Bar project - that just seems the most convenient.


--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

On 24 April 2013 07:01, Pieter Nagel <[hidden email]> wrote:
Put the user into the loop. Let the user choose the ultimate version
in the case where Metacello can't unambiguously decide. But at the
same time, ConfigurationOfs should not depend on particular versions
of _Monticello_packages_, but on _other_ConfigurationOfs_. Maven uses
an exclusion filter: in Metacello terms it'd be something like

spec
  package: 'ConfigurationOfBar' with: '1.1';
  package: 'ConfigurationOfBar' without: '1.2'

"Deliberately exclude Bar version 1.2 from my list of dependencies"

I'm not _against_ semantic version. It's a fine ideal towards which to
strive. I don't think it's a silver bullet, but as long as we can
agree there are out-of-band things needed (communication with library
maintainers, for instance), let's move on.

Agreed. See above regarding depending on ConfigurationOfs rather than
individual Monticello packages.

> Secondly, because when other people go and declare dependencies on small
> slices of other libraries implementation details, then they take
> responsibility on their shoulders for getting that part's dependencies
> right. And at best, that is duplicate, redundant code. At worst, you'll
> get it wrong.
>
> I think practices like these are just a recipe for dependency hell.

So in Ruby you declare your dependencies in a Gemfile. Lots of folk
use version ranges here (or no versions at all!), and when they run
"bundle install" they get a Gemfile.lock which shows the actual,
explicit, exact versions of things loaded. When apps actually run, the
Gemfile.lock tells you what exact versions of everything you'll use.
In particular, you can _edit_ this, which means you can _control_
which version of Bar you use.

I think that letting the user override versions of things would go a
long way towards solving the problem. I mean, OK, version ranges would
allow Metacello to "get it right" automatically with higher
probability. They wouldn't definitively solve the problem.

That's a fair point. And if you couldn't control your transitive
dependencies it'd be game over. So you want Metacello to provide
intercession hooks, where the user can help resolve conflicts between
versions.

However, you can easily have the situation where half your
(transitive) codebase _needs_ Bar 1.1 and the other half _needs_ Bar
1.2. Side-by-side loading's the only thing that can save you here. But
I'll grant it's off topic for this thread.

> With semantic versioning, one package would have depended on XML-Reader
>>= 3.4.1, another would have dependend on version >= 3.4.7, and when the
> bugfix version 3.4.99 came along, one could load that and EVERYONE could
> have used that,

That's great. But as the maintainer of a library, how can I know what
versions of XML-Reader my users use? My problem with semantic
versioning is that you need to exercise judgement in whether or not
you're making a breaking change to your API. It's simply not a
solvable problem (I've tried) because you have no control over how
people use your library.

>> Do you mean that you want metadata allowing you to take an image and
>> know what version of what package you have installed? (Kind've like a
>> dynamically generate Gemfile.lock.)
>
> No, I mean I want the version numbers to be visible and in your face.
> For example, in the Monticello browser (at least for a ConfigurationOf
> package).

This is kind've what I meant. Given an image, what libraries are
loaded and what versions? (And I don't care what the revision IDs are
of all the internal components, thanks.)

> At the moment, wherever you click, you only see numbers like
> Bar-UI-JohnDoe.101.mcz which carry zero semantic version info. If you
> wnat the version number, you have to go call the Metacello API and query
> it for what is loaded.

Right. You don't care about the internal packaging of a project.

> No wonder the de-facto practice is for people to just declare
> dependencies on Bar-UI-JohnDoe.101.mcz instead of on a range of versions
> of the Bar project - that just seems the most convenient.

Well, that's your leverage point, isn't it? You make the right thing
easy to do, and everything else harder.

frank

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
 
 

How does Metaceller functionality compare to Versioneer ?

Diego Lont wrote:

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

In some ways the functionality is similar, but the focus is different.

The main focus of Metaceller is to maintain your Metacello Configuations. And that means you need to be able to view, modify and test this configuration (loading it) in several ways. So the next feature that I probably want is to be able distinguish between the different platforms (i.e. Seeing in Pharo 2.0 what gets loaded in Gemstone or Pharo 1.4)

What I understood is that the aim of Versioner is more directed at updating for configuration while developing. Which involves a lot of the same features.

On Apr 27, 2013, at 2:20 AM, Ben Coman wrote:

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Pieter,

Thanks for taking the time to comment in great detail. This is good fodder for discussion ...

First some general comments and then I will embed specific comments/replies to your post.

I'd say that with Metacello, I've tried to supply some fairly general mechanisms that make it possible for developers to do what they need to do to specify the dependency structure of their project.

On the loading side, I'd say that Metacello provides a fair amount of flexibility for developers until it comes to dependency conflict resolution ... In the currently released version of Metacello (1.0-beta.31.1.6), Metacello always favors the latest version of a project: Metacello will automatically upgrade a loaded project, but it will never automatically downgrade a loaded project.

With the new Metacello Scripting API, the onConflict:, onUpgrade: and onDowngrade: family of messages provide a measure of load-time control over conflict management and I've eliminated the "automatic upgrade" policy ... Now the full control lies in the hands of the developer doing the load. Again, I am trying to provide some fairly general mechanisms.

I don't want Metacello to be in the enforcement business ... Metacello is intended to be used for cross-platform development and it is unreasonable to assume that the same development conventions will be followed on all platforms even though they may be sharing the same projects.

Just because Metacello isn't in the enforcement business doesn't mean that I don't think enforcement is necessary, I just think that enforcement should take place at a different level: tools or community.

I expect communities to evolve in terms of the conventions being followed and I don't want Metacello to be an impediment to such evolution ... it's why I try to use general mechanisms and balk at building conventions into Metacello itself. Symbolic versions has simply added a tag mechanism to Metacello. I chose to have an explicit tag (using Symbols) rather than implement a lookup order version strings. The use of #stable is a community convention and that convention can be changed without breaking Metacello.

With the Metacello Scripting API release, developers of individual projects will be able to choose whether or not they want to use Semantic Versioning. If (when) I add version range support to Metacello, then developers that depend upon a project that claims to adhere to Semantic Versioning will be able to leverage that and specify dependencies using version ranges ...  

If a community decides to adopt Semantic Versioning (as the Ruby community has with their use of ruby-gems) then it is presumed that all projects will use Semantic Versioning, but if an odd project comes along that does not happen to use Semantic Versioning, at least Metacello won't prevent a development from specifying a dependency upon the project.

Further commentary embedded below...

Dale


----- Original Message -----
| From: "Pieter Nagel" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, April 23, 2013 1:04:05 PM
| Subject: Re: [Metacello] the future of #stable in Metacello
|
| I believe that if the Metacello world were to migrate to using Semantic
| Versioning, a lot of things would vastly improve.

I agree. Semantic Versioning is aimed at addressing the real world problem of "dependency hell" and to quote from the spec[1]:

  In systems with many dependencies, releasing new package versions can
  quickly become a nightmare. If the dependency specifications are too
  tight, you are in danger of version lock (the inability to upgrade a
  package without having to release new versions of every dependent
  package). If dependencies are specified too loosely, you will
  inevitably be bitten by version promiscuity (assuming compatibility
  with more future versions than is reasonable). Dependency hell is
  where you are when version lock and/or version promiscuity prevent
  you from easily and safely moving your project forward.

Semantic Versioning is not necessarily the only solution, but adhering to any sort of convention for version naming would vastly improve things at this point:)

[1] http://semver.org/

|
| I've been engaged at a client who uses both GemStone and Pharo to
| upgrade their dependencies on third party systems such as Seaside,
| Grease, Magritte, and so on, and I must say, down in the trenches, the
| state of the art in Smalltalk packaging seems to be "dependency hell".
|
| The norm seems to be for, say, Foo to depend on Bar-UI-xyz.101.mcz and
| Baz-Core-abc.102.mcz, while Baz-Core in turn depends on
| Bar-UI-xyz.102.mcz.

If you are using Metacello for this then I assume that you are referring to the fact that you have two external projects A and B that you depend upon and they both depend upon different versions of the same project C and one version of C uses Bar-UI-xyz.101.mcz and the other version of C uses Bar-UI-xyz.102.mcz.

Not a big deal, but Metacello only allows project dependencies to be specified upon versions of projects and not on versions of packages ... (just for clarity)

|
| Metacello will, heroically, apply some heuristics to try and get the
| resuling system loaded by for example first loading Bar-UI-xyz.101.mcz
| and then later loading Bar-UI-xyz.102.mcz as needed.
|
| And everytime I see situations like that I cross my fingers and think:
| "sheesh, I hope there were no backwards-incompatible changes between
| Bar-UI-xyz.101.mcz and Bar-UI-xyz.102.mcz, because if any slip through
| testing, the client is going to blame me".

But Semantic Versioning does not "solve" this problem ... it just changes your worry to "sheesh, I hope these guys were disciplined and didn't slip in an API change without bumping the major version that slips through my testing..." or to "sheesh, I hope the developers of project A and B didn't use a bit of private API that has been changed in an incompatible way in Bar-UI-xyz.102.mcz that slips through my testing...."

With that said, if someone claims to follow Semantic Versioning or another published version naming scheme, you can at least make the assumption you will be safer.

|
| But, frankly, this is wrong. Metacello's role should be to take
| packagers at their word and very strictly apply what they say. If the
| packagers "lie" and give a stricter dependency than what they intend to,
| my feeling is: tough cookies - let them learn to specify their
| dependencies correctly.

I basically agree with this sentiment ... as I implied in my general comments above, I really don't like the "automatic upgrade" feature and will remove it when the Metacello Scripting API is released.... Okay, "REMOVE" is too strong a word. When using the old-style load statements like:

  (ConfigurationOfMyProject version: '1.0.0') load

Metacello will continue to do "automatic upgrades", but if one uses the style:

  Metacello new
    configuration: 'MyProject';
    version: '1.0.0';
    repository: '...';
    load.

A load conflict error will be signalled when it is discovered that a different version of project C is required during the load.

When a load conflict occurs you can complain the developers of projects A and B and C and ask them to get their acts together and then patiently wait while some action is taken. But, while you wait for them to resolve the issue, you can continue with your own _development_ and use one the onUpgrade:, onDowngrade: or onConflict: family of messages to pick your own poison (deny or allow the upgrade/downgrade/conflict).

You may not want to ship under these conditions, but development is a different issue.

|
| And the only correct way to specify those dependencies would be for Foo
| to say "I depend on Bar-UI >= 10.3.1 and < 11", and for Baz to say "I
| depend on Bar-UI >= 10.3.2 < 11". That way, Monticello at least has a
| hope to determine that the entire collection of packages will indeed
| have their dependencies satisfied by Bar-UI 10.3.2, so I'll load that,
| and only that, once.
|
| I would like a world where:
|
| 1. Semantic versioning, in the sense of depending on range of versions
| that are intended to be compatible, becomes the norm, the easiest to
| express in Metacello's API, and the only thing one sees on "how to use
| Metacello" docs.

As I've stated in my comments above, I don't want Metacello to dictate a particular versioning scheme ... Metacello will provide the mechanism, but the community must supply the enforcement.

|
| 2. Depending on specific versions such as Bar-UI-xyz.101.mcz be
| absolutely disallowed by Metacello - with the only exception that
| ConfigurationOfBar is allowed to tie a specific version of the Bar
| project to specific mcz.that provide, say, Bar-UI and Bar-Core and the
| like.

Metacello already doesn't allow dependencies to be specified at the monticello file level, one can specify a dependency on a package name, but not on a specific version of a package. I think the problem that you are seeing is because the conflict lies at the project level and that Metacello does the "automatic upgrade" trick.

|
| 3. Before Metacello loads a set of dependencies, it walks the transitive
| closure of all dependencies and just flat our refuse to load in cases
| where one package needs Bar version X and another needs Bar version Y.
| This will place pressure on the authors of the respective
| ConfigurationOf... classes, to write their packages with sane
| dependencies  on a range of versions . If you wrongly say that your
| package only works with Bar version 10.1.2 instead of saying it works
| with Bar version >= 10.1.2 and < 11, well, then that's your fault, not
| Metacello's fault.

With the Scripting API (`Metacello new....`) this will be the standard behavior.
|
| 4. Metacello itself seems to contain a lot of complexity that seems to
| be designed as a workaround for the fact that the community does not use
| semantic versioning. The new scripting API, onUpgrade: hooks and the
| like seem to be at least partially motivated by a desire for the user to
| be able to say "You know, that package over there wants A-12345.mcz, but
| I happen to hope that A-12346.mcz should work too, so let me add this
| hook to override what the packagers said". I think the desires and
| use-cases for feature like these would vastly reduce if, instead, the
| upstream packagers would just do sane, semantic, versioning!

The onUpgrade:, onDowngrade, and onConflict: methods were actually added to address the types of problems encountered when one decides to "fork a project" to fix bugs, add new features, etc. When one forks a project one must be able to declare "use my version of project X located over here" and that declaration has to be honored by Metacello when loading any other projects that may depend upon project X.

And just to reiterate, Metacello does not give developers control over package versions ... all of the decisions (like onUpgrade: and friends) are made relative to project versions, so you are making a decision between using version 3.1 and 3.2, not A-12345.mcz versus A-12346.mcz.

Like I said, I prefer to create general mechanisms that can be used to address a class of problems, rather than narrow features than knock off one problem at a time ... The fact that these general features can be used for evil as well as good is a side effect.

What's important to me about this is that the decision to resolve the conflicts is made by the load expression and not by changing a configuration somewhere so the fact that conflicts exist is very visible ...

Presumably the community can act to enforce their chosen conventions if there are too many published load scripts that are forced to use onUpgrade: and friends...

|
| 5. The actual version number of a package one is using and has loaded is
| "in your face:. I've spent the past few months downloading
| foo-dkh.651.mcz files and whatnot, but it is very rare when one can
| easily determine "oh, what i've got hold of here is version 3.0.4 of the
| foo project". My impresssion is that a lot of the projects don't really
| care what their version numbers are; and if they don't care, how can the
| users take care to know what version ranges they depend on?

I agree that a lot of the version numbers used by projects are pretty meaningless, I agree that a documented version numbering scheme is required and I agree that Semantic Versioning is a good example of a version numbering scheme goes a long way towards addressing the problem of "dependency hell" .... If the spec is adhered to...

... I am curious how Semantic Versioning works in practice, especially  in the ruby community ... Do the Semantic Versioning police swoop down on a project and punish developers for changing the API without bumping the major version number or are developers more in the habit of simply forking in self defense those projects that can't be trusted to adhere to the Semantic Versioning spec  or does everyone fanatically follow the Semantic Versioning spec?

Dale

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Pieter and Frank,

I think I've pretty much stated my thoughts/positions in my recent email. I do intend to support version range specification in the not to distant future, but it is my opinion that it is up to the community to adopt/enforce a version numbering scheme. Version range dependencies don't work if the version numbers are meaningless.

In the end I think that we are in "screaming agreement."

But Pieter, I am curious about the fact that you claim that it is common practice for developers to define dependencies upon specific Monticello file versions. I would love to see specific examples of this practice (private mail would be fine).

I can think of several different mechanisms that might be used for that evil purpose, but I've never seen anything approaching that in the wild and I can't imagine how they are doing it so I can't imagine how Metacello would be able to tell the difference between illegal usage and legal usage ...

If I see some examples I might be able to define a validation rule that will complain about it and make it possible for the community developed tools to call out violations...

Dale

----- Original Message -----
| From: "Pieter Nagel" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, April 23, 2013 11:01:22 PM
| Subject: Re: [Metacello] the future of #stable in Metacello
|
| On Tue, 2013-04-23 at 22:51 +0100, Frank Shearar wrote:
| > On 23 April 2013 21:04, Pieter Nagel <[hidden email]> wrote:
|
| > > 2. Depending on specific versions such as Bar-UI-xyz.101.mcz be
| > > absolutely disallowed by Metacello - with the only exception that
| > > ConfigurationOfBar is allowed to tie a specific version of the Bar
| > > project to specific mcz.that provide, say, Bar-UI and Bar-Core and the
| > > like.
| >
| > Why? These correspond precisely to git commit IDs or svn revision IDs.
| > A version tag, semantic or otherwise, is just a label applied to one
| > of these.
|
| If a project Foo depends on a specific, SINGLE version of Bar, then that
|  means that Foo is making massive assumptions about every other package
| installed alongside it in the same image.
|
| It either presumes that:
|
| 1) Nobody else is going to depend on Bar, and so it does not need to
| take into account whether their version of Bar will satisfy other
| packages too,
|
| or 2) That everybody else who is going to use Bar will be happy with the
| exact same single version that Foo is using.
|
| In practice, this is unworkable. In the real world, people all kinds of
| other packages of the shelf at Squeaksource, packages that the author of
| Foo did not even know existed. And in the real world, those packages,
| under the hood, then also depend on Grease, or XML-Writer, or whatever -
| but some other, different version of that package.
|
| In the real world (without some sort of semantic versioning), you end up
| with dozens of packages, each of which depends on a different version of
| something. And Metacello can only satisfy ONE of those dependencies, at
| most. For everyone one of the rest, its a matter of crossing your
| fingers and hoping that the packages will still work even though the got
| a slightly different XML-Writer (for example) than they declared a
| dependency on.
|
| The core of the issue here is that depending on a SINGLE version of
| somebody else's code is a no-no. Whether that dependency is declared on
| a Monticello package name, Git commit SHA id, or tag tied to a specific
| commit, or a symbolic version number "3.0.4.1-beta2", is implementation
| detail.
|
| The only sane way for packages to coexist in an ecosystem of other
| packages, is for them to depend on a RANGE of versions, say >= 3.4.1 and
| < 4, just for example. Then at least the packaging system has a hope of
| finding a version that satisfies everybody.
|
| The flip side of this, of course, is that whoever assigns a version
| number to the packages they release, must also behave predictably, and
| not break backwards compatibility unless they also bump their major
| version number.
|
| The semantic versioning spec that Dale linked to is one way to achieve
| that.
|
| > Ah. No, you're saying that you should only declare dependencies on a
| > library - Bar 1.1, say - rather than parts of a library. It's _Bar's_
| > responsibility to say "version 1.1 uses Bar-UI-xyz.101.mcz", right?
| > (This doesn't matter for single-package libraries, mind you.)
|
| Right. Firstly, because, as I said, depending on a specific SINGLE
| version of any one thing can fundamentally just not work in an ecosystem
| (unless that "thing" is an implementation detail purely under your
| control that no one else will refer to).
|
| And Monticello packages have only a SINGLE name, i.e.
| Bar-UI-xyz.101.mcz. It is Metacello that assigns version numbers, and
| that's the arena where semantic versioning can hopefully play out.
|
| Secondly, because when other people go and declare dependencies on small
| slices of other libraries implementation details, then they take
| responsibility on their shoulders for getting that part's dependencies
| right. And at best, that is duplicate, redundant code. At worst, you'll
| get it wrong.
|
| I think practices like these are just a recipe for dependency hell.
|
| > With today's tech, I agree. There are other possibilities, but they
| > require a lot more work. Newspeak allows side-by-side loading of
| > modules. Squeak 4.5's Environments could well supply a similar ability
| > to, in one Environment Ex, load Bar version X and in another
| > Environment Ey load Bar version Y. Ex and Ey can export their
| > definitions without exposing which version of Bar they use.
|
| But let's suppose this kind of facility is available, and Metacello can
| make use of it on all the platforms it runs on.
|
| Without semantic versioning, Metacello will have no hope of knowing
| whether it really NEEDS to load a different XML-Reader for every package
| that uses it, or whether the authors were just sloppy in declaring
| dependencies on single versions instead of ranges. In practice, it will
| end up loading loads of different versions of XML-Reader.
|
| Now, a security bug is found in XML-Reader, and they make a minor patch
| release. But if you go and load the bugfix, then NONE of the packages
| will end up using it, because they each still depend on their own
| specific versions of XML-Reader. No, you will have to wait for each and
| every on of the other packages to release updates that declare a
| dependency on a newer XML-Reader that includes this bugfix.
|
| With semantic versioning, one package would have depended on XML-Reader
| >= 3.4.1, another would have dependend on version >= 3.4.7, and when the
| bugfix version 3.4.99 came along, one could load that and EVERYONE could
| have used that,
|
| > Do you mean that you want metadata allowing you to take an image and
| > know what version of what package you have installed? (Kind've like a
| > dynamically generate Gemfile.lock.)
|
| No, I mean I want the version numbers to be visible and in your face.
| For example, in the Monticello browser (at least for a ConfigurationOf
| package).
|
| At the moment, wherever you click, you only see numbers like
| Bar-UI-JohnDoe.101.mcz which carry zero semantic version info. If you
| wnat the version number, you have to go call the Metacello API and query
| it for what is loaded.
|
| No wonder the de-facto practice is for people to just declare
| dependencies on Bar-UI-JohnDoe.101.mcz instead of on a range of versions
| of the Bar project - that just seems the most convenient.
|
|
| --
| You received this message because you are subscribed to the Google Groups
| "Metacello" group.
| To unsubscribe from this group and stop receiving emails from it, send an
| email to [hidden email].
| For more options, visit https://groups.google.com/groups/opt_out
|

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

On 28 April 2013 02:17, Dale Henrichs <[hidden email]> wrote:

> ... I am curious how Semantic Versioning works in practice, especially  in the ruby community ... Do the Semantic Versioning police swoop down on a project and punish developers for changing the API without bumping the major version number or are developers more in the habit of simply forking in self defense those projects that can't be trusted to adhere to the Semantic Versioning spec  or does everyone fanatically follow the Semantic Versioning spec?


I've been working entirely in Ruby for the last year or so, at work. I
haven't seen any _punishment_. If we find bugs in a 3rd party gem, we
fork it and fix locally, issuing a pull request upstream. When/if the
upstream maintainer applies the PR (so far that's happened very
quickly) and publishes a new version (people seem to accumulate a
bunch of changes before upgrading), we use that. But generally it
seems people more or less follow Semantic Versioning.

But having said that, that's just my experience. I'm not subscribed to
any of the Ruby mailing lists, so I'm not really in the community. Oh,
one additional datum is that in the AMQP side of things people (like
Michael Klishin) _do_ rather tightly follow semantic versioning rules.

frank

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Frank,

Then there's hope for Semantic Versioning to work in the Smalltalk community ... it's not quite as easy to do fork/fix/pull request with mcz files, but presumably with Semantic Versioning as a guideline, developers will make an effort to conform as much as possible...

Dale

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: [hidden email]
| Sent: Sunday, April 28, 2013 2:43:20 AM
| Subject: Re: [Metacello] the future of #stable in Metacello
|
| On 28 April 2013 02:17, Dale Henrichs <[hidden email]> wrote:
|
| > ... I am curious how Semantic Versioning works in practice, especially  in
| > the ruby community ... Do the Semantic Versioning police swoop down on a
| > project and punish developers for changing the API without bumping the
| > major version number or are developers more in the habit of simply forking
| > in self defense those projects that can't be trusted to adhere to the
| > Semantic Versioning spec  or does everyone fanatically follow the Semantic
| > Versioning spec?
|
|
| I've been working entirely in Ruby for the last year or so, at work. I
| haven't seen any _punishment_. If we find bugs in a 3rd party gem, we
| fork it and fix locally, issuing a pull request upstream. When/if the
| upstream maintainer applies the PR (so far that's happened very
| quickly) and publishes a new version (people seem to accumulate a
| bunch of changes before upgrading), we use that. But generally it
| seems people more or less follow Semantic Versioning.
|
| But having said that, that's just my experience. I'm not subscribed to
| any of the Ruby mailing lists, so I'm not really in the community. Oh,
| one additional datum is that in the AMQP side of things people (like
| Michael Klishin) _do_ rather tightly follow semantic versioning rules.
|
| frank
|
| --
| You received this message because you are subscribed to the Google Groups
| "Metacello" group.
| To unsubscribe from this group and stop receiving emails from it, send an
| email to [hidden email].
| For more options, visit https://groups.google.com/groups/opt_out
|

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Hi Diego,

I did not forget about your announcement. I am still going through it. There are things that I would like changed, but nevertheless we now have a first robust solution for in-image configuration development.

I will come back with suggestions (and code modifications :)).

Cheers,
Doru


On Apr 26, 2013, at 4:35 PM, Diego Lont <[hidden email]> wrote:

--
www.tudorgirba.com

"Every thing has its own flow."




--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Hi Doru,

Feel free to improve on the tool. Some things I agree are not very neatly coded.

Cheers,
Diego

> Hi Diego,
>
> I did not forget about your announcement. I am still going through it. There are things that I would like changed, but nevertheless we now have a first robust solution for in-image configuration development.
>
> I will come back with suggestions (and code modifications :)).
>
> Cheers,
> Doru
>

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Pieter Nagel-3 wrote

The only sane way for packages to coexist in an ecosystem of other
packages, is for them to depend on a RANGE of versions, say >= 3.4.1 and
< 4, just for example. Then at least the packaging system has a hope of
finding a version that satisfies everybody.
...
The semantic versioning spec that Dale linked to is one way to achieve
that.

My hunch in using Metacello has verified this. Where I now say #stable (e.g. in a baseline), I want to say, by default e.g. "3.0.1 or any subsequent version that doesn't break backward compatiblity", and I could foresee a situation where I would not be able to glean this info automatically (i.e. a config developer did not follow semantic versioning) and might have to manually specify a range.

Maybe part of the API could declare semantic versioning. Something like:
spec
  repository:...;
  blessing:...;
  beSemantic
or maybe easier (won't have to declare each version... although the former might be safer. Tools such as Versionner that could optionally enforce sem ver could stamp each version sem ver)
ConfigurationOfXyz class>>#isSemantic returning false by the default template and overridden in specific projects

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Sunday, June 16, 2013 7:50:12 PM
| Subject: [Metacello] Re: the future of #stable in Metacello
|
| Pieter Nagel-3 wrote
| > The only sane way for packages to coexist in an ecosystem of other
| > packages, is for them to depend on a RANGE of versions, say >=
| > 3.4.1 and
| > < 4, just for example. Then at least the packaging system has a
| > hope of
| > finding a version that satisfies everybody.
| > ...
| > The semantic versioning spec that Dale linked to is one way to
| > achieve
| > that.

The only sane way for developers to survive in an ecosystem of other packages is for everyone to _religously_ follow a version naming convention...

I have had support in Metacello since about day one of the RubyGem twiddle-waka[1] range operator, but until developers show discipline and a willingness to adhere to something like Semantic Versioning, I haven't promoted it's use ... now that there finally appears to be interest I will have to blow the dust off that operator and make sure that it works as advertised:)

Actually I imagine that it will be necessary to allow one to specify a version string using the operator ... something like the following:

  spec project: 'Seaside30' with: [
    spec
      versionString: '~>3.0.8';
      ...]

and the #stable version could be specified like this:

  stable: spec
    <symbolicVersion: #'stable'>
    spec for: #'pharo1.4.x' version: '1.0.2'.
    spec for: #'pharo2.x' version: '~>1.0.2'.
    spec for: #'pharo3.x' version: '~>1.0.3'.

[1] http://robots.thoughtbot.com/post/2508037841/rubys-pessimistic-operator
|
| My hunch in using Metacello has verified this. Where I now say
| #stable (e.g.
| in a baseline), I want to say, by default e.g. "3.0.1 or any
| subsequent
| version that doesn't break backward compatiblity",

The #'~>' operator would allow you to say use 3.0.1 through 4.0 which is the Semantic Versioning way of saying "I have not broken backward compatibility"

| and I could
| foresee a
| situation where I would not be able to glean this info automatically
| (i.e. a
| config developer did not follow semantic versioning) and might have
| to
| manually specify a range.

But what range can you safely specificy ... If developers don't follow semantic versioning specifying any version from the future is unsafe ...

Ranges would be useful I suppose after the fact, to identify the range of versions that was known to work ... but I'm not convinced that anyone will be that discerning ... It will certainly complicate the version resolution logic to allow ranges and it will certainly lead to needless version deadlock if a developer specifies too narrow a range for a project ...

I know that version ranges are theoretically useful but I'm afraid that needing version ranges is an indication that there is something else wrong in the system (i.e., why don't I change my code so that I don't need to specify a narrow range or why don't the maintainers of projects make backward compatible changes and maintain multiple forks if necessary to avoid forcing people to specify a range of versions in self defense)...

I think that with the Metacello Scripting API it is possible for a developer to define which versions she wants to use for a particular project in a particular image by selectively allowing upgrade/downgrade/conflict during the load operation, in the event that they are forced to use poorly managed projects .

|
| Maybe part of the API could declare semantic versioning. Something
| like:
| spec
|   repository:...;
|   blessing:...;
|   beSemantic

In the Metacello Preview you can specify which version number class to use:

  versionNumberClass
    ^ MetacelloSemanticVersionNumber

or

  versionNumberClass
    ^ MetacelloVersionNumber

The version number class enforces the syntax for each version numbering scheme (additional version numbers schemes can be added) as well as defining the semantics for comparison...

The developers are responsible for adhering to the semantics of the version numbers:)

| or maybe easier (won't have to declare each version... although the
| former
| might be safer. Tools such as Versionner that could optionally
| enforce sem
| ver could stamp each version sem ver)
| ConfigurationOfXyz class>>#isSemantic returning false by the default
| template and overridden in specific projects

I think that a project is either using semantic versioning or it is not ... you can't switch version horses midstream, because the whole notion is that you have consistent sematics across the whole version range ...

Now that there is some genuine interest in doing this better I'd like to kick around the idea that we embed the range operators in the version strings for projects, you may use a version expression as well:

  '3.0.8'
  '~>3.0.8'
  '3.0.5:3.0.8'
  '<=3.0.8'

I haven't though a lot about this, but it seems to be a natural way to handle this...

Tell me I'm crazy:)

Dale

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

On 17 June 2013 17:16, Dale K. Henrichs
<[hidden email]> wrote:
Well, I don't know. That kind've condemns old projects to
"non-semantic hell, where you burn for all eternity". I don't see a
problem with people saying "as of version N, we will follow semantic
versioning principles".

And, of course, people can make mistakes, and break something that
they didn't mean to. (Been there, done that.) But hey, it's not like
you'll run out of versions: bump the patch number, say sorry, and
carry on.

It is possible to go too far in avoiding structure in strings, but I'd
just like to mention "don't embed structured data in strings!". The
problem being that `'3.0.8' asVersion fuzzy` or `'3.0.8' asVersion
orEarlier` is a bit wordy. Great for tools, not so great for reading
specs.

frank

> Dale
>
> --
> You received this message because you are subscribed to the Google Groups "Metacello" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: [hidden email]
| Sent: Monday, June 17, 2013 9:39:38 AM
| Subject: Re: [Metacello] Re: the future of #stable in Metacello
|
| On 17 June 2013 17:16, Dale K. Henrichs
| <[hidden email]> wrote:
| >
| > I think that a project is either using semantic versioning or it is
| > not ... you can't switch version horses midstream, because the
| > whole notion is that you have consistent sematics across the whole
| > version range ...
|
| Well, I don't know. That kind've condemns old projects to
| "non-semantic hell, where you burn for all eternity". I don't see a
| problem with people saying "as of version N, we will follow semantic
| versioning principles".

One can use MetacelloVersionNumber and claim to follow the Semantic Versioning spec. So you can switch midstream.

The MetacelloSemanticVersionNumber adds support for pre-release and build metadata syntax and ordering.

One can construct version numbers that look a lot like Semantic Versions with MetacelloVersionNumber, but in some of the more obscure use cases the sort order will differ from Semantic Version ordering.

|
| And, of course, people can make mistakes, and break something that
| they didn't mean to. (Been there, done that.) But hey, it's not like
| you'll run out of versions: bump the patch number, say sorry, and
| carry on.

Thats's understood.

BUT once you say you intend to follow the Semantic Version spec, you need to follow the spec (mistakes are part of development).

If you *intentionally* make changes that are not backward compatible without incrementing the MAJOR version number (the hardest commitment to make when following the spec) then you are not really following the spec and it would have been better if you never pretended to follow it in the first place:)


|
| > Now that there is some genuine interest in doing this better I'd
| > like to kick around the idea that we embed the range operators in
| > the version strings for projects, you may use a version expression
| > as well:
| >
| >   '3.0.8'
| >   '~>3.0.8'
| >   '3.0.5:3.0.8'
| >   '<=3.0.8'
| >
| > I haven't though a lot about this, but it seems to be a natural way
| > to handle this...
| >
| > Tell me I'm crazy:)
|
| It is possible to go too far in avoiding structure in strings, but
| I'd
| just like to mention "don't embed structured data in strings!". The
| problem being that `'3.0.8' asVersion fuzzy` or `'3.0.8' asVersion
| orEarlier` is a bit wordy. Great for tools, not so great for reading
| specs.

Thanks for nipping this in the bud:)

Frankly there is currently a "clean" way for specifying all of the operations except the range operation:

  spec
    configuration: 'Seaside30' with: [
      spec
        version: '3.0.8';
        operator: '~>'; "default is '>=', but any of the comparison operators may be used"
        .... ]

[DISCLAIMER ... while the above is supposed to work, I am almost certain that it will not work properly in all cases]

A range spec won't be quite as well contained ... I probably need something like the following:

  spec
    configuration: 'Seaside30' with: [
      spec
        version: '3.0.8' to: '3.1.55';
        .... ]

and error messages for naked #version: and #operator: in combo with #version:to:...

But maybe something like the above isn't so bad:)

Dale


     

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

On Jun 17, 2013, at 8:53 PM, Dale K. Henrichs wrote:
I don't like the idea of heaving an operator work on the version string. A.t.m. the version has to be an exact match …either with a symbol or a version. I do agree that it would be very nice to be able to specify a range. But than I also want a possibility to say a certain version comes after a certain other version.

Adding something like:
version020: spec
        <version: '0.2.0' upgrades: #('0.1.0' )>

To allow to specify what version comes after what.

Also I think allowing a regular expression (instead of an operator) would add something. Then you would have a spec looking like this:

        spec
                configuration: 'Seaside30' with: [
                        spec
                                versionExp: '3.0.*';
                                …

The says you want the most recent version that matches the regular expression 3.0.*. This also allows for some more complex specifications of the version you want and also work for versions like  4.alfa // 3.1.beta … and allowing you to say: versionExp: '*.beta' (I want the latest beta release)

Diego

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

----- Original Message -----
| From: "Diego Lont" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, June 18, 2013 12:30:40 AM
| Subject: Re: [Metacello] the future of #stable in Metacello
|
| I don't like the idea of heaving an operator work on the version
| string. A.t.m. the version has to be an exact match …either with a
| symbol or a version. I do agree that it would be very nice to be
| able to specify a range. But than I also want a possibility to say a
| certain version comes after a certain other version.
|
| Adding something like:
| version020: spec
| <version: '0.2.0' upgrades: #('0.1.0' )>
|
| To allow to specify what version comes after what.

Semantic Versioning[1] addresses exactly this problem by specifying the sematics of each field in the version string: MAJOR.MINOR.PATCH.

I think your suggestion is interesting but explicitly building upgrade paths just adds another dimension in which developers can make mistakes:) For example, if no upgrades clause is defined, how am I to interpret version 0.2.0?

Semantic Versioning claims that a developer has two degrees of freedom in defining upgrade version numbers: MINOR and PATCH. When the MAJOR version is incremented she is declaring that the release is NOT an upgrade.

The important thing here is the when I write a project reference spec:

  spec project: 'Seaside30' with: [
    spec
      version: '3.0.8';
      operator: '~>`;
      ....]

I am making allowances for what I think the developers of Seaside30 are going to do. If they are following Semantic Versioning I can be assured that my project spec will be valid for versions from '3.0.8' up to but not including '3.1.0' and that I am accounting for any PATCHES that may be released and excluding all MINOR and MAJOR upgrades.

If developers are allowed to decide the upgrade path at the time they release the upgrade how can I predict what they will do?

[1] http://semver.org/

|
| Also I think allowing a regular expression (instead of an operator)
| would add something. Then you would have a spec looking like this:
|
| spec
| configuration: 'Seaside30' with: [
| spec
| versionExp: '3.0.*';
| …
|
| The says you want the most recent version that matches the regular
| expression 3.0.*. This also allows for some more complex
| specifications of the version you want and also work for versions
| like  4.alfa // 3.1.beta … and allowing you to say: versionExp:
| '*.beta' (I want the latest beta release)
|

I'm not convinced that regular expressions are better than using operators.

If you don't include operators, how would you express the following using regular expressions `> 3.1.3'? If you want to specify ranges, how do you do that with regular expressions?

Take a look at the "Specifying Versions" chapter of the RubyGems User Guide[2]. They have a good writeup on using operators with version strings.

I think the expression `~> 3.0.0` does an adequate job of expressing what you intended by '3.0.*'.

It is possible to reason about pre-release versions, too. Using Semantic Versioning, '~> 3.0.0-` would state that you will accept any pre-release version up to but not including the `3.0.0` release.

The fundamental problem with pre-release versions is that one needs to know what patterns the developers will follow in their naming conventions ... Again you must anticipate the names of _future_ versions when you write regular expressions .... Operators along with a definition of version order and semantics for the various bits of that make up the version string; make it possible for a developer to write explicit expressions using operators that resolve to a set of FUTURE versions with well understood semantics.

Dale

[2] http://docs.rubygems.org/read/chapter/16

--
You received this message because you are subscribed to the Google Groups "Metacello" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.