I also think it's worth noting that libraries don't need to wait before they can depend on a specific version of Elixir before fixing all the deprecation warnings of the versions before that version. You can do something like we do in Gettext for example ( https://github.com/elixir-lang/gettext/blob/9fcb138f949185079921f7a26ae1c342587e2235/lib/gettext/po/parser.ex#L176-L178) in order to support multiple Elixir versions without emitting warnings during compilation. The gist is:
# TODO: remove once we depend on Elixir 1.5 and on. chunk_every = if function_exported?(Enum, :chunk_every, 2), do: :chunk_every, else: :chunk defp enum_chunk_every(enum, n), do: apply(Enum, unquote(chunk_every), [enum, n]) or something along those lines. Andrea Andrea Leopardi [email protected] On Sat, Feb 24, 2018 at 2:59 AM, José Valim <[email protected]> wrote: > The issue is that @since does not mean when a function has been deprecated > but when it was added. So the information you are requesting is not > available right now (although it could be made available). > > But honestly, the best answer would be to reduce the amount of > deprecations. > > We are very aware of the amount of deprecations Elixir emits and it has > been our goal to reduce them. v1.6 already had less deprecations than v1.5 > and we hope we will continue this trend with v1.7. The issue is that > changes to our deprecation policy takes a while to have an effect because > they are long term. > > > > *José Valimwww.plataformatec.com.br > <http://www.plataformatec.com.br/>Founder and Director of R&D* > > On Sat, Feb 24, 2018 at 11:06 AM, Thomas Depierre < > [email protected]> wrote: > >> Hi, >> >> I want to say upfront that i know this kind of proposal happened before, >> and i know the stance is "if you disable warnings, why have warnings at >> all" if i remember correctly. Which i support. >> >> That said, i think there is now an opportunity for a new discussion >> around a particular kind of tuning for warnings. >> >> *Proposal* >> Tag all elixir deprecation with @deprecated and @since (hard ?) >> >> Offer a flag to restrict deprecation warnings to only warnings before a >> given version. It could be a flag to mix for xref like: >> >>> --only-deprecated-before 1.6 >> >> >> This would only generate warnings for deprecations that are anterior to >> deprecation in 1.6+ >> >> *Why ?* >> >> 1. The compile flag --warnings-as-errors do make sense to use, among >> other reasons due to warnings like this one: >> >>> function Foo.bar/0 is undefined (module Foo is not available) >> >> because they do tend to be real errors in the code most of the time. >> (I know there have been some discussions for elixir 2.0) >> >> 2. Elixir is deprecating a lot recently on each versions. Which is great, >> but make for a really noisy output on CI, especially when some dependencies >> want to keep compatibility with 1.4+ ( a good example is Phoenix recently). >> But it also happens a lot if you want to compile with 1.6 locally your >> library to get better error message and all, but you target 1.4+ for the >> user of your library. >> >> Now that we have the @deprecated and the @since attributes, there is a >> window to offer the possibility to filter these warnings for deprecations. >> >> It would benefit CI noisiness and make it easier to support library >> maintainer that want to bump up their versions support without going full >> bleeding edge. Yes they can compile with the old version and will probably >> keep doing it, but when newer versions also provides niceties for >> development... >> >> *Why not ?* >> >> Some of my own counter arguments : >> Hard to do. And useless before 1.6 as we do not have @deprecated and >> @since before that. >> Small value added, you should develop and compile with the version you >> target. >> Deps warning are already ignored for `--warnings-as-errors` >> Hiding warnings is a bad pattern, as people will not fix their stuff. >> This is not doable right now without the change coming with 1.7, or would >> need more changes. (no idea if true here) >> >> >> Would love to hear your thoughts on it. I would happily take a swing at >> trying to work on that if the team want to go with it. >> >> Thomas Depierre >> >> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/elixir-lang-core/1268ddba-55a1-43dd-84a8-af3919873211% >> 40googlegroups.com >> <https://groups.google.com/d/msgid/elixir-lang-core/1268ddba-55a1-43dd-84a8-af3919873211%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/CAGnRm4KqHLneG0TWakDWjGBah7SHU > 0gYQ21f-W-Y79%3DOXpnbsQ%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KqHLneG0TWakDWjGBah7SHU0gYQ21f-W-Y79%3DOXpnbsQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2B%2BveKtZtDbz%3DVH6jPfHdVoXY5fZ88F%2BnMiWE3X-6uEqFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
