Re: handling versioning change

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

Yeah, that fails the taste, POLS, understandable, desirable and wanted tests.

On 27 November 2016 at 10:07, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
> On 27.11.2016 18:21, Alistair Crooks wrote:
>> 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
>>>
>
> I don't like to request from users to manually handle package renaming
> or removing in order to install smaller & newer version. It should work
> out of the box.
>
> PKGEPOCH mechanism would solve it now and add a proper tool in future,
> adding incremental version prepending PKGVERSION, PKGEPOCH 1 would form
> a version like 1:1.0.3, that will be always higher than any version with
> the default PKGEPOCH 0.
>
> http://rpm.org/max-rpm-snapshot/s1-rpm-depend-manual-dependencies.html
>