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 <mag...@therning.org> wrote: > On 30 April 2015 at 10:21, Nicola Squartini <tens...@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: mag...@therning.org jabber: mag...@therning.org > twitter: magthe http://therning.org/magnus >
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/arch-haskell
