You are not logged in.

#1 2017-12-30 08:34:56

Salkay
Member
Registered: 2014-05-22
Posts: 618

[SOLVED] Dealing with upstream's versioning

I am the maintainer for vim-diffchar. Upstream just upgraded from 7.32 to 7.4. However, pacman thus considers the new version to be earlier than the previous version. Is the only way to handle this by bumping the epoch in the PKGBUILD? My problem with this is that I'd have to bump the epoch regularly, if upstream continues with this versioning scheme, but I can't see any other way to fix the PKGBUILD.

Last edited by Salkay (2017-12-31 22:58:19)

Offline

#2 2017-12-30 10:33:36

WorMzy
Forum Moderator
From: Scotland
Registered: 2010-06-16
Posts: 11,783
Website

Re: [SOLVED] Dealing with upstream's versioning

Unfortunately there's not much you can do retrospectively. You could vet the releases, adding a minor version to the pkgver where appropriate (e.g. instead of 7.32, use 7.3.2) and either store the upstream version in a variable, or use string manipulation to remove the extra period where necessary. Bumping the epoch would be easier and less misleading to the end users though.

The best thing to do, imo, would be to talk to upstream and ask them to use a more sane versioning scheme.


Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD

Making lemonade from lemons since 2015.

Online

#3 2017-12-30 12:24:43

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: [SOLVED] Dealing with upstream's versioning

WorMzy wrote:

Bumping the epoch would be easier and less misleading to the end users though.

I agree for the isolated case this would be good, but as this is likely to continue, this could get messy: the epoch number would basically become the version number.

Looking at the upstream version numbers it's almost always X.Y except in a few cases I could only speculate that he was drunk typing and added an extra digit X.YZ, but X.Y is always still sequential.  With all existing versions, you could just trim to 2 digits (X.Y) and everything would work, but to deal with the potential of these seemingly random digits eventually becoming meaningful, you could right-pad with zeros: so 6.4 becomes 6.40 which is greater than 6.32.  This would work with all the existing version number of this package, and would work with extension of the current trend.

This would be much like WorMzy's idea of adding a period, except that you'd have to go back and change 6.32 to 6.3.2 which you can't do.  Right padding with a zero requires no retroactive changes: just submit 6.40 to the AUR now.

(edit: s/to/no/)

Last edited by Trilby (2017-12-31 23:11:44)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#4 2017-12-31 22:58:08

Salkay
Member
Registered: 2014-05-22
Posts: 618

Re: [SOLVED] Dealing with upstream's versioning

Thank you both for your replies.

WorMzy wrote:

The best thing to do, imo, would be to talk to upstream and ask them to use a more sane versioning scheme.

Probably a good idea, although upstream has been a bit unresponsive, not answering a request to add a licence from 1.5 years ago.

I agree with WorMzy, in that adding a minor version would be confusing. But I also agree with Trilby that continually bumping the epoch is messy.

I've decided to go with Trilby's suggestion of right padding with zeros. I feel like this is consistent with what upstream means by 6.4 anyway. It's still a bit deceptive to the end user, but works well enough. Thanks again.

Offline

#5 2017-12-31 23:30:23

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: [SOLVED] Dealing with upstream's versioning

Salkay wrote:

I've decided to go with Trilby's suggestion of right padding with zeros. I feel like this is consistent with what upstream means by 6.4 anyway. It's still a bit deceptive to the end user, but works well enough. Thanks again.

If you find it deceptive, then you can probably add the real version in the description. I'm not completely sure if the AUR policy allows that, though.


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Offline

#6 2018-01-01 00:57:40

Salkay
Member
Registered: 2014-05-22
Posts: 618

Re: [SOLVED] Dealing with upstream's versioning

progandy wrote:

If you find it deceptive, then you can probably add the real version in the description. I'm not completely sure if the AUR policy allows that, though.

Good idea. I'll keep it in mind if this problem recurs. Thanks.

Offline

Board footer

Powered by FluxBB