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
