Release 3.3

[takluyver]

@tacaswell @aragilar I'd like to get 3.3 out soon. Here are some things I'm aware of that I'd like to see finished for that:

• Fix h5py exceptions and new libver "v114" #1875 - compatibility with HDF5 1.12.1 & 1.14
• Add default cast from H5T_NATIVE_B8 to uint8 #1889 - convert bitfield data to unsigned ints by default (changes requested)
• Improvements to assembling virtual datasets #1905 - improvements to assembling virtual datasets
• Deprecate setting default_file_mode, only allow setting to 'r' #1839 - deprecate setting default file mode (to be decided)
• [ ] Deprecate 'with dset.astype()' #1842 - deprecate using .astype() to modify dataset state (to be decided)

[aragilar]

• Fix h5py exceptions and new libver "v114" #1875: Looks good to me, disappointing about the duplication though
• Deprecate setting default_file_mode, only allow setting to 'r' #1839 and Deprecate 'with dset.astype()' #1842: I think get those in as soon as possible, as they're both changes people should be making to their code anyway.
• Improvements to assembling virtual datasets #1905: Looks fine, I'm not that familiar with VDS, and given the change seemed driven by the needs of users, merging it should be fine.
• Add default cast from H5T_NATIVE_B8 to uint8 #1889: I think the main thing it needs (other than @takluyver comments) was the changes in the FAQ (I'm undecided whether it should have some additional documentation around how to use such datatypes, maybe a bit out of scope for h5py).

[tacaswell]

If @aragilar is OK waiting one more release for the ds.astype, I think we should wait. I merged #1839 and I think the discussion on #1905 is converged.

[aragilar]

I'm happy to wait.

[takluyver]

@ajelenak said last week (on #1875) that HDF5 1.12.1 would be relased 'soon'.

I'm thinking of trying to release h5py 3.3 before that, so that there's a compatible h5py ready to use for anyone upgrading HDF5 straight away. But there's also a case for waiting so that we can test it and upload wheels built with HDF5 1.12.1. Does anyone want to push for that?

[tacaswell]

I have lost track of how automated our wheel building process is right now, but if it is not too much work how about doing h5py3.3.0 with hdf5 1.10.x and h5py3.3.1 with hdf5 1.12.1 ?

That way we can get wheels out here relatively quickly, but also give people an easy way to back out of the 1.12.1 if they need to.

[takluyver]

The actual building is fully automated on Azure, but to make a release I've been downloading them manually and then uploading them to PyPI.

I might wait to see how much pressure there is to do another release with the new HDF5 version. I'm not sure I want to set a precedent that an HDF5 bugfix release automatically means an h5py release, and people can always rebuild h5py if they need a different HDF5 version. But depending on how big the improvements are, it might make sense to do a release relatively soon.

[ajelenak]

@ajelenak said last week (on #1875) that HDF5 1.12.1 would be relased 'soon'.

I was told this morning the release should happen by the end of this week.

[takluyver]

The release is done 🙂