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