getXdgDirectory accepts relative path in XDG_CACHE_HOME

[phadej]

#87 was nonsense, as I commented in that issue.

Relative XDG_CACHE_HOME just doesn't make any sense, relative to what.

https://www.freedesktop.org/wiki/Specifications/basedir-spec/ links to latest, which says

All paths set in these environment variables must be absolute. If an implementation encounters a relative path in any of these variables it should consider the path invalid and ignore it.

There's even the source: https://github.com/freedesktop/xdg-specs/tree/master/basedir with history, https://github.com/freedesktop/xdg-specs/commits/master/basedir/basedir-spec.xml

[phadej]

Also, that change was made in a patch version, so now I cannot even use CPP to workaround it. It's observable change, not good.

[bgamari]

Indeed we should try to get this fixed for GHC 8.8.2 and 8.10.1.

[Rufflewind]

There's even the source: https://github.com/freedesktop/xdg-specs/tree/master/basedir with history, https://github.com/freedesktop/xdg-specs/commits/master/basedir/basedir-spec.xml

Thanks for the clarification. It is good that freedesktop.org has now clarified which one of the conflicting specs is canonical.

Also, that change was made in a patch version, so now I cannot even use CPP to workaround it. It's observable change, not good.

At the time, this issue was believed to be a bug and as such the fix only required a patch version bump. Most bugs require observable changes to fix, so that criterion alone does not indicate what kind of version bump is preferred.

[phadej]

From https://pvp.haskell.org/

Non-breaking change. Otherwise, if only new bindings, types, classes,
non-orphan instances or modules (but see below) were added to the interface,
then A.B MAY remain the same but the new C MUST be greater than the
old C. Note that modifying imports or depending on a newer version of another
package may cause extra non-orphan instances to be exported and thus force a
minor version change.

Other changes. Otherwise, e.g. if change consist only of corrected
documentation, non-visible change to allow different dependency range etc.
A.B.C MAY remain the same (other version components may change).

The bug change you mention above falls into Non-breaking change category. PVP is well written to avoid ambiguities between "what's a new feature and what's a bug fix".

And for important library as directory, I'd rather error on the safe side.

Technically, changing the behavior of existing functions may be interpreted even as breaking change, and I won't be surprised (though not positively), if someone relies on some bug behavior in library like directory (luckily PVP has a loophole, SHOULD vs MUST, so one can fix issues which e.g. prevented the use completely)

[Rufflewind]

Consider following up on haskell/pvp#15. I don't believe the decision is as clear-cut as it seems since the difference only manifests in unusual XDG environment configurations.

[phadej]

As I said, in a non-clear cut situations one have to error on the safe-side. I hope we agree, that bare patch version bump was wrong, and learn from that.