I wanted to gather some thoughts on whether projects should develop Julia 0.7 versions of their packages rather than attempt to Compat the development. Many languages do so when they go through a major version upgrade (e.g., Python 2 and Python 3). Since Julia 0.7 is basically the pre-release of Julia 1.0 shouldn’t the development follow this practice and develop a different versions from Julia 0.x? Currently the only version that is supported is the latest major releases (Julia 0.6x) as previous version were dropped. This should allow for cleaner syntax and faster code as it would deal with depreciations and would be able to work without the Compat code. It would also foster and propagate the latest changes in the language which would help newcomers and general users/developers to familiarize themselves with the latest syntax and features.
For the most part, Compat.jl allows you to simply write the newer APIs and syntaxes exactly as you would were you only supporting 0.7. In the cases where that’s not true, there’s the @compat macro or explicit version checks. While that adds a bit of visual cruft, bots like Femtocleaner can automatically remove them as you update your version bounds.
Using Compat.jl doesn’t really do anything when run on the latest version — it’s basically just a no-op. IMO: do as you see fit based upon your own projects, your own bandwidth, and your users.
Stefan has a great post talking about the pitfalls of the chicken-and-egg problem of trying to get everyone to jump to 1.0 simultaneously, looking to Python’s pain points as inspiration.
Most of the project I have contributed use Compat and Femtocleaner (when is up an running is great!). However, when running older versions using Compat it can lead to suboptimal performance depending on the solution or if it requires many workarounds. Stefan’s post does make good points. However, the side by side comparison might not hold that much water… Python 2 had a huge time memorial established user base and ecosystem. Julia 0.x still hasn’t hit the Julia 1.x stage. I am a lot more worried about users transitioning to 1.x and developers lagging. Compat is not a perfect solution. It is a great tool, but it supports up to Julia 0.5 if not mistaken having dropped 0.4x not too long ago. I think that if there are some points when it makes sense to transition it is best to do them at opportune times.
Developing for both ecosystems many times leads to writing for the previous version and relying on the new version to handle the depreciated syntax without too much noise… When the depreciations drop in Julia 1.0 it might pose a serious lag in development.
Do what you want. I don’t tend to care about compatibility all that much in pre-1.0 because everyone wants to upgrade anyways, and people who don’t want to upgrade tend to not want me changing their packages (they’re staying because of stability!). So I try a little bit to make it work, but if it would take a few hours to make one obscure feature work on a previous version, see it as a valuable use of my time and just up the minimum version.
After some problems with Compat back in the 0.4 → 0.5 transition, we moved to the “clean slate” approach – that is, we tag a final package version for the soon-to-be-superseded version of Julia, and then tag a new version for the upcoming version. It looks like this and allows us to remove Compat as a dependency as well as ensure our optimizations take advantage of new Julia features.
We are currently in the process of doing the same thing for the 0.6 → 0.7 transition as well.