Article discussing Go, could well be D

[Johannes Pfau]

Jacob Carlborg wrote:
>[...]
>I hope this explains most of the things and I'm sorry for any
>confusion I may have caused.

Thanks for that detailed explanation, I think I understand. This system
also seems more flexible than the traditional 'this directory will be
the root of the package, copy all files to be packaged into this
directory'

>Ok, I think I understand so far. I was thinking something similar. But 
>is a four digit version really necessary?

I thought of variable length version numbers, this is what most package
management systems use. Whats wrong with variable length versions?
Look at 'compareBaseVer' in the source linked later for an example of
how to compare such versions.

>This got quite complex. When I was thinking about SCM integration I
>was thinking about you only specify the address to the repository,
>which will mean the latest commit on the main branch. Then you could
>also specify tags, branches and perhaps specific commits. But you
>could never specify, for example, a release (or commit) newer then
>another commit. This wouldn't work:
>
>orb "dwt", "~> 0.3.4", :git =>
>"git://github.com/jacob-carlborg/libjson.git"
>
>I see now that I've specified a version in the git example on the
>wiki. This was a mistake, I removed the version now.
>

I think we look at 2 different approaches here: If I understood
correctly you want to allow the _user_ to grab the lastest git version.
Whenever he wants to update, he has to do that manually. He also always
downloads the source code and compiles it on his machine (no binary git
packages).

My approach let's the _packager_ create git packages. From these source
packages binary packages can be build and distributed to end users like
any other package (release, prerelease). Snapshots are 'first
class packages', which means everything working with releases and other
packages will also work with snapshots.
The downside of this approach is that it complicates things a lot. It
needs a versioning scheme capable of sorting snapshots, releases and
prereleases reliably.

Here's some proof of concept code:
https://gist.github.com/1035294
200 LOC for a versioning scheme seems to be alot though.
-- 
Johannes Pfau