Killing or resurrecting version tags for good

Hello all, A while back, I was nattering around the parsing code for Cabal, and I noticed that Cabal still had code for parsing version tags, but was explicitly *not* printing out version tags. I proposed that we should get rid of the parsing code as well, but when I mentioned this on #ghc Mark Lentczner (cc'ed) mentioned that they were using version tags to identify different versions during a build, e.g. what Git version things correspond to. I am not going to claim to know the right answer to this question, but in either case, it is terrible that we are PARSING tags but not PRINTING them. This leads to terrible error messages, among other things, such as in this case: $ ghc-pkg describe json-0.7-foo ghc-pkg: cannot find package json-0.7 (NB: json-0.7 is installed.) So if we're keeping tags around, at least for the immediate future, then we should print them; otherwise, we should get rid of them entirely! Edward

Hi,
On 26 July 2014 23:36, Edward Z. Yang
Hello all,
A while back, I was nattering around the parsing code for Cabal, and I noticed that Cabal still had code for parsing version tags, but was explicitly *not* printing out version tags. [...]
So if we're keeping tags around, at least for the immediate future, then we should print them; otherwise, we should get rid of them entirely!
IIRC, Duncan wants to remove version tags both from Cabal and Data.Version. So perhaps it's time to deprecate them.

Excerpts from Mikhail Glushenkov's message of 2014-07-26 23:44:39 +0100:
IIRC, Duncan wants to remove version tags both from Cabal and Data.Version. So perhaps it's time to deprecate them.
My question here is orthogonal to the question of deprecation: if we are deprecating them, but not removing them, we should still print the tags while we still ostensibly support them! Edward
participants (2)
-
Edward Z. Yang
-
Mikhail Glushenkov