[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: handling versioning change
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
>> 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 22.214.171.124 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.
> 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.
Main Index |
Thread Index |