Article discussing Go, could well be D

Jacob Carlborg doob at me.com
Mon Jun 20 03:20:44 PDT 2011


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.

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

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

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list