Re: handling versioning change

[Alistair Crooks <agc%pkgsrc.org@localhost>]

There's always 4)

Pick a new PKGBASE name - lz4github, or lz4zip, to represent the
change-of-versioning-scheme

and 5)

ignore it, just change the version number, and rely on the exact new
version for a period (3 months?) during which time people will do the
upgrade almost by default





On 27 November 2016 at 06:31, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> On Sat, Nov 26, 2016 at 10:45:57AM -0500, Greg Troxel wrote:
>>   1) just change the version and people will have to deal, once
>
> Just make sure to add some appropiate limits to avoid the old version
> where necessary.
>
>>   2) do something like 132.1.7.3 and be kludgy forever
>
> More like go with 999a1.7.3 or so. That's reasonable dense and still
> orders well.
>
>>   3) Implement some silent metadata in versions just for tools that
>>   check versons, so that the human-presented version is right.  I dimly
>>   recall discussion of this (EPOCH?) but can't find it.
>
> All epoch syntaxes are more or less as bad as the above, some just stick
> the marker to the end.
>
> Joerg
>