
Release numbers would still be reset on adding:
xrev == 0 -->
haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz
add xrev == n && n > 0 --> haskell-zlib-0.5.4.2-1.n-x86_64.pkg.tar.xz
add <next ver>, xrev == 0 -->haskell-zlib-<next ver>-1-x86_64.pkg.tar.xz
The only concern that I have with your versioning is that having 0.x in the
release number might suggest that the package is still in a testing stage.
And I make xrev == 0 first class (not adding the ".n") because I believe
Hackage revisions are ugly and should not exist.
Anyway, whatever scheme you choose it's good for me :)
On Thu, Apr 30, 2015 at 5:59 PM, Magnus Therning
On 30 April 2015 at 10:21, Nicola Squartini
wrote: Sorry, keep replying to one person only instead of the mailing list.
How about the other way around:
if xrev == 0 --> haskell-zlib-0.5.4.2-76-x86_64.pkg.tar.xz if xrev == n && n > 0 --> haskell-zlib-0.5.4.2-76.n-x86_64.pkg.tar.xz
There are implementation details in `cblrepo` that make things a lot easier if the release number is reset when a package is added (an update is treated as an addition of an already existing package). As it is now the algorithm doesn't keep track of packages that are updated, but with your scheme it would have to (the release number must be carried over). Furthermore, if the algorithm is modified in that way there is no need to even include the x-revision at all, it can all be "hidden" in a bump of the release number.
/M
-- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus