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

[Liliana Marie Prikler]

Am Donnerstag, den 02.09.2021, 07:53 +0000 schrieb Jonathan McHugh:
> 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.
ChangeLogs are generally not installed as part of packages, though some
packages might include them as documentation.  In other cases, they
might even be part of the source files themselves, Emacs packages
sometimes function like that.  In either case, they only "address" the
problems insofar as reading them might give a clue about what goes into
the resulting binary, but they do not help that much with versioning.

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