Just for my curiosity: How is actually Compat synchronised with language changes / deprecations in Julia? I followed twice today the recommendation in the deprecation warning (like replace this( with that( ) and later on learned, that Compat is actually not able to provide a backward compatible solution.
This is open source. You can make the missing implementation to Compat.jl yourself. I am sure a lot of people are willing to help.
2 Likes
There’s no automatic synchronization: all the changes are implemented by various developers updating Compat.jl. You can browse all the merged and pending changes here: Pull requests · JuliaLang/Compat.jl · GitHub
1 Like
I have marked your answer as the solution, because it’s technically and actually right. This is open source and everyone here is able to help and if needed her- or himself.
However, i’m actually really disappointed by the situation, as the people evolving or changing the language seem to have a different concept of responsibility for the existing ecosystem.
If you would ask more concrete question, you would get better answers. If you ask that how one should implement this exact depreciation to Compat.jl I believe people are eager to help. I feel frustrated a lot times with open source but I remind myself: this is somebody’s hobby. It’s not like I am paying anything to him or her to fix my problem.
While in general I agree with the sentiment (it’s open source, just make a PR), some package in the Julia ecosystem are somewhat special in the sense that they require knowledge about Julia’s internals, or a decision about solving a particular problem that comes up. Compat.jl is one of these, and while I am sure that contributions are welcome, the initial investment for making one may not be trivial.
Please keep in mind that it is summer in the northern hemisphere, and many people are on a vacation. Consider the upside: coming back well-rested from their holidays, everything should be fixed 
1 Like
I am very thankful that Andreas is maintaining Cairo.jl being a core package of the Julia ecosystem.
The deprecation messages usually do not care about 0.6 and maintaining compatibility needs special attention.
My suggestion: make a stable 0.6 Release and Go with 0.7 only on master. This will make your life easier unless you are doing any feature development.
Well technically JuliaGraphics is the maintainer and i just happen to be someone with commit rights. And i’m planning to stop this once we reached a stable 1.0 (and maybe the split into Cairo, CairoText, CairoPango). And be more a Cairo user, like i started.
For how to handle 0.6 and 0.7/1.0, i have somehow lost track what is recommended to depend on. The general story line was: Compat will enable to have backward compatible code. But this is already not the case. Compat right now transforms dev (0.7) into stable (0.6.4). In most cases.