[Top][All Lists]

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

Re: Can we find a better idiom for unversioned packages?

From: Jonathan McHugh
Subject: Re: Can we find a better idiom for unversioned packages?
Date: Thu, 02 Sep 2021 07:53:23 +0000

Hi Liliana,

Given your examples I expect improving upstream CHANGELOG (or third party) 
files would be too much of a burden in order to solve the aforementioned 


September 1, 2021 11:47 PM, "Liliana Marie Prikler" 
<> wrote:

> Am Mittwoch, den 01.09.2021, 19:48 +0000 schrieb Jonathan McHugh:
>> September 1, 2021 8:35 PM, "Liliana Marie Prikler" <
>>> wrote
>> Making our rando commit git versions look like such other distro
>> versions does come at a disadvantage though, particularly when we
>> look
>> at it through the lense of someone not used to Guix' versioning
>> scheme.
>> Instead of telling us "yeah, this is the Nth time we picked a rando
>> commit since the last release and this time it's de4db3ef", users
>> coming from such distros would assume "oh well, this is still good
>> ol'
>> 1.0 with some more patches applied". So while the commit itself
>> does
>> not give us any particularly useful information (unless you're that
>> person who uses this part of the version string to look the commit
>> up
>> on hubbucket), especially not when thinking in the context of
>> versioning scheme, it does provide the existential information of
>> "hold
>> on, this is not a release commit, it's something else" and might
>> thus
>> direct users to be a little more attentive when they'd otherwise go
>> "yep, upstream considers this solid and Guix considers it even more
>> solid, so it's the solidest". Note, that this can be overcome both
>> by
>> teaching/learning about it and by using a special sigil as
>> mentioned
>> above.
>> Perhaps a function revealing metadata based upon the version string
>> would allow more people get an overview without visiting hubbucket^1?
> I don't think that information is actually encoded anywhere nor
> immediately obvious unless you're vaguely familiar with said software,
> but it's still important e.g. if reading the documentation. Does this
> feature mentioned in the frobnicatorinator 1.44 docs apply to 1.36 or
> not? Do the examples from some book written in the early 70s work if I
> compile them with GCC 12? And so on and so forth.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]