tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: handling versioning change

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 <> 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 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.

Attachment: signature.asc
Description: OpenPGP digital signature

Home | Main Index | Thread Index | Old Index