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 <magnus@therning.org> wrote:
On 30 April 2015 at 10:21, Nicola Squartini <tensor5@gmail.com> 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