Article discussing Go, could well be D

[Johannes Pfau]

Jacob Carlborg wrote:
>On 2011-06-20 10:46, Johannes Pfau wrote:
>> 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.
>
>Currently I have the three-part-version as default and then a custom 
>version (which basically can contain anything). The reason for the 
>three-part-version scheme is explained in the wiki.

So it's to have defined semantics for version changes, to standardize
thing like api breakage. I think this makes sense, although it forces a
special versioning scheme on users it might be worth it.

>>> 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).
>
>Yes.

It probably comes down to the questions if binary 'git' packages are
worth the effort. I only know linux distribution package management
systems where it's common to package snapshots. But it might be
overkill for a package system dealing mostly with libraries.

>
>> 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.
>
>I don't think I understand your approach.
>

It might really be overkill. But consider this example:
package FOO requires libjson >= 0.0.1 as a dynamic library.
package BAR requires latest libjson from git as a dynamic library.

now FOO could use libjson-git, but how does the package manager know
that? It cannot know whether the git version is more recent than 0.0.1.
It's also not possible to install both libraries at a time, as both are
dynamic libraries with the same name.
We now have a conflict where you can only install FOO or BAR, but not
both.

-- 
Johannes Pfau