Compatibility

[simonbyrne]

How should we make this compatible wth current functionality, so that users don't see a bunch of method overwritten warnings?

Some options:

• Make the package 0.5 only: this will be a problem if we want to extend the package beyond the functionality available in Base (which was part of the reason of making it a package...)
• Don't export methods on 0.4, e.g. so that a user on 0.4 would need to explicitly import Primes: isprime.

Combinatorics.jl has trod this path already (though it was already a package beforehand); @jiahao any thoughts here?

[jiahao]

You could wrap the definitions for the removed functions in a

if VERSION < v"0.5-"
...
end

block.

Ultimately, the only sane thing to do in Combinatorics.jl was to simply maintain separate branches for 0.4 and 0.5, since it became really messy to deal with other breaking changes like how collect() worked in the tests.

[simonbyrne]

Thanks, good to know. In that case, I might register it as-is, so that we can remove it from Base, and then we can make the above change.

[hayd]

The other option is to add a Compat entry, so that @compat using Primes would be a no-op in 0.4-.

[ararslan]

Ref JuliaLang/julia#16481