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

["Jonathan McHugh" <indieterminacy@libre.brussels>]

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


Jonathan

September 1, 2021 11:47 PM, "Liliana Marie Prikler" <leo.prikler@student.tugraz.at> wrote:

> Am Mittwoch, den 01.09.2021, 19:48 +0000 schrieb Jonathan McHugh:
> 
>> September 1, 2021 8:35 PM, "Liliana Marie Prikler" <
>> leo.prikler@student.tugraz.at> 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.