The draft of the 3 release policy has a very strict requirement for warnings, "without causing warnings even when compiled with -Wall". This causes breaking changes to be spread out over a number of years because of deprecation warnings. I propose that "-Wall" in this sentence be replaced with "-Wall -Wno-compat". As we are addressing an audience who wish to suppress a specific category of warnings, it seems reasonable to ask that they make this explicit. (I would also prefer for -Wcompat to be on by default, but that would be another discussion, if and only if this proposal is accepted.) -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp58232... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
Hi, Am Sonntag, den 29.11.2015, 01:37 -0700 schrieb Jeremy:
The draft of the 3 release policy has a very strict requirement for warnings, "without causing warnings even when compiled with -Wall". This causes breaking changes to be spread out over a number of years because of deprecation warnings.
I propose that "-Wall" in this sentence be replaced with "-Wall -Wno-compat". As we are addressing an audience who wish to suppress a specific category of warnings, it seems reasonable to ask that they make this explicit.
my impression was that "-Wall" would not imply "-Wno-compat", bringing the policy in line with what you intend it to do. And I agree that this is the sensible policy. If that’s not the case, we should consider if it maybe should be the case :-)
(I would also prefer for -Wcompat to be on by default, but that would be another discussion, if and only if this proposal is accepted.)
Indeed a different, but worthwhile discussion. As always, I’m far from having a fixed opinion, but want to note that a lot of code is _not_ library code, and compatibility with one GHC version at a time is all that matters, and (momentarily) irrelevant warnings are annoying. That’s a point in favor of _not_ having it on by default. Greetings, Joachim -- -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
The current design is that -Wcompat will be off by default and includes
warnings that are not in -Wall and that we'll be introducing warnings into
-Wall when they become actionable under a 3 release policy rather than the
more eager approach you are advocating here.
So you'll still get warnings before the changes go into effect, but with
-Wcompat you get a _lot_ of notice for when you don't care much at all
about backwards compatibility, but really want forward compatibility above
all.
-Edward
On Sun, Nov 29, 2015 at 3:37 AM, Jeremy
The draft of the 3 release policy has a very strict requirement for warnings, "without causing warnings even when compiled with -Wall". This causes breaking changes to be spread out over a number of years because of deprecation warnings.
I propose that "-Wall" in this sentence be replaced with "-Wall -Wno-compat". As we are addressing an audience who wish to suppress a specific category of warnings, it seems reasonable to ask that they make this explicit.
(I would also prefer for -Wcompat to be on by default, but that would be another discussion, if and only if this proposal is accepted.)
-- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp58232... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Edward Kmett-2 wrote
The current design is that -Wcompat will be off by default and includes warnings that are not in -Wall and that we'll be introducing warnings into -Wall when they become actionable under a 3 release policy rather than the more eager approach you are advocating here.
Yes, I understand that that is the current design, and I'm asking whether this could be adjusted. Do we lose anything by the proposed change to the policy, other than authors who want 3-release -Wall-clean code adding an extra flag? (Or maybe I just didn't understand you - are you saying that introducing new warnings are not a bottleneck for any changes?) -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp58232... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
Regardless of if -Wcompat is on by default or not, the timeline for changes
wouldn't change. The only thing that would change is that we'd be asking
library authors to use
-Wall -Wno-compat
which they can't do on old versions of GHC, so it'd become a bigger burden
for the lion's share of library maintainers; they'd have to explicitly
guard the -Wno-compat flag on the GHC version in their cabal file.
At least those who _want_ -Wcompat are explicitly looking forward and it
seems right to put the burden on that smaller subset than change the game
for every library maintainer.
Mind you if a -Wcompat user isn't looking to support old versions, they
also have no burden.
But, again, switching the default wouldn't gain you any time on any
outstanding proposal.
-Edward
On Mon, Nov 30, 2015 at 3:10 AM, Jeremy
The current design is that -Wcompat will be off by default and includes warnings that are not in -Wall and that we'll be introducing warnings into -Wall when they become actionable under a 3 release policy rather than
Edward Kmett-2 wrote the
more eager approach you are advocating here.
Yes, I understand that that is the current design, and I'm asking whether this could be adjusted. Do we lose anything by the proposed change to the policy, other than authors who want 3-release -Wall-clean code adding an extra flag? (Or maybe I just didn't understand you - are you saying that introducing new warnings are not a bottleneck for any changes?)
-- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp58232... Sent from the Haskell - Libraries mailing list archive at Nabble.com. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Edward Kmett-2 wrote
Regardless of if -Wcompat is on by default or not, the timeline for changes wouldn't change. The only thing that would change is that we'd be asking library authors to use
-Wall -Wno-compat
which they can't do on old versions of GHC, so it'd become a bigger burden for the lion's share of library maintainers; they'd have to explicitly guard the -Wno-compat flag on the GHC version in their cabal file.
At least those who _want_ -Wcompat are explicitly looking forward and it seems right to put the burden on that smaller subset than change the game for every library maintainer.
Mind you if a -Wcompat user isn't looking to support old versions, they also have no burden.
But, again, switching the default wouldn't gain you any time on any outstanding proposal.
I'm not proposing (at this point) to turn on -Wcompat by default, just to allow warnings that can be turned off with -Wno-compat as an exception to the 3-release policy. Guarding -Wno-compat in .cabal doesn't seem like an excessive burden (one copy-and-paste per package), but if the change won't bring any benefits, it's a moot point (for now). -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp58232... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
Hi, Am Montag, den 30.11.2015, 04:13 -0700 schrieb Jeremy:
I'm not proposing (at this point) to turn on -Wcompat by default, just to allow warnings that can be turned off with -Wno-compat as an exception to the 3-release policy.
do you mean warnings that are _in_ -Wall – which the warnings in -Wcompat are not? Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
Joachim Breitner-2 wrote
do you mean warnings that are _in_ -Wall – which the warnings in -Wcompat are not?
Yes. -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp58232... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
Am Montag, den 30.11.2015, 05:04 -0700 schrieb Jeremy:
Joachim Breitner-2 wrote
do you mean warnings that are _in_ -Wall – which the warnings in -Wcompat are not?
Yes.
but then these warnings are not affected by -Wno-compat! (I.e. the warning set "all" and the warning set "compat" are disjoint.) I’m confused. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org
More to the point, the policy does allow for telling library authors that they must rewrite their code into something that "may not necessarily be idiomatic". Adding a caveat to .cabal is trivial compared to replacing code with something ugly/clunky/non-idiomatic. An additional issue is that if code is going to break, I would like to change it in one go and be done with it. The current policy of drip-feeding bits and pieces of change requires me to manage the transition piecemeal over a number of years. The very example on the wiki page shows how the same code has to be rewritten twice, over the course of a 5 year transition. The spirit of the 3 release policy is a good compromise. However, the requirement for Wall-and-only-Wall clean compilation feels fanatical. It seems to be creating a straw-man persona, someone who doesn't care how often they have to change their code or what they have to change it into, as long as it compiles Wall-clean with no version-specific flags, and demands that they get exactly what they want without any compromise. -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp58232... Sent from the Haskell - Libraries mailing list archive at Nabble.com.
participants (3)
-
Edward Kmett -
Jeremy -
Joachim Breitner