Add deprecated bindings for backwards compatibility with ecosystem packages

[jmert]

Namely, get the tests of JLD.jl and MAT.jl to pass again.

As noted in the new deprecated.jl file, PRs #629 and #632 have broken JLD.jl and MAT.jl for current HDF5.jl master. This PR restores them to working order by adding a bunch of deprecation methods.

Of particular note is re-adding default property values to the d_create method — JLD.jl was already using the method and relying on the fact that it only had to provide 2 out of the 4 property lists. I'm also preparing a PR to MAT.jl which ends up using this method as well to fix an error it has after #631.

PRs #629 and #631 have already been tagged in minor releases v0.13.3 and v0.13.4, respectively, so it'd be nice to get some form of deprecated backwards-compatibility layer in place so that until a major version bump is made, external packages continue to work.

[musm]

@jmert thanks for this !

I created a release-0.13 branch, where I dropped several of the newer commits on master such as #632 and related commits that require a major version bump.

In particular, if we could get the deprecations for PRs #629 and #631 into release-0.13 branch, I believe that should be sufficient for a new patch tag.

[jmert]

That sounds good. Would you like me to split this PR up into two — this one with just the changes relevant to the v0.13 branch, and then take the deprecations for #632 and make that a separate PR against master?

(Related to that, I could backport my #645 change to the v0.13 branch since I'd like to use that functionality sooner rather than later :-) )

[musm]

(Related to that, I could backport my #645 change to the v0.13 branch since I'd like to use that functionality sooner rather than later :-) )

👍

That sounds good. Would you like me to split this PR up into two — this one with just the changes relevant to the v0.13 branch, and then take the deprecations for #632 and make that a separate PR against master?

👍

[jmert]

OK, I think I've rebased this one onto the release-0.13 branch correctly — both MAT.jl and JLD.jl's tests passed for me locally.

[musm]

great. Would be good if those packages got updated in the future.

[jmert]

That sounds good. Would you like me to split this PR up into two — this one with just the changes relevant to the v0.13 branch, and then take the deprecations for #632 and make that a separate PR against master?

+1
...
OK, I think I've rebased this one onto the release-0.13 branch correctly — both MAT.jl and JLD.jl's tests passed for me locally.

I just realized that I did this backwards, but oh well — this PR should have stayed against master since it will need all deprecations (to give packages a clear upgrade path to v0.14), and then a new PR should have contained only the deprecations due to #629 to fix the v0.13 compatibility.

New PR incoming for master.

[musm]

Should I wait before creating a new patch release on 'release-0.13'?

[jmert]

No, I think release-0.13 is OK to go. I just had to do a bit of fiddling around to get a sane master PR again.