Fixing improper workflow for v1.1.1 #46
Conversation
Co-authored-by: Devin Huyghebaert <devin.huyghebaert@gmail.com>
Co-authored-by: Devin Huyghebaert <devin.huyghebaert@gmail.com>
Release pyDARNio v1.1
* Checks borealis version to determine how to verify blanked samples. * Different verification for versions < v0.6 and >= v0.6 * If untagged version, tries both verifications
* Used np.array_equal() instead of == * Clarified exception message and docstring
and lp_status_word missing from rawacf hdf5 file.
* Follows exact same format as check for rawacf -> rawacf
file when converting to iqdat. * If not, puts a zero in their spot in iqdat file * Exact same check as for rawacf hdf5 -> rawacf dmap
Rawacf dmap conversion
…an's to int array. * unsigned ints (blanked_samples and beam_nums) will overflow
…in a record. * Methods __convert_bfiq_record and __convert_rawacf_record affected
…cf hdf5 files to dmap.
Bugfix: Nan assignment of integer types
Multi-beam Record Conversion
Remove far lag0 replacement when converting rawacf hdf5 files to dmap.
Version 1.1.1
Updating links in README file for correctly built readthedocs documentation.
There was a problem hiding this comment.
This all looks fine to me, pretty sure these are all my edits in the docs anyway haha.
There's a couple of things that need updating but I think it's proper to do them in the release branch anyway. I don't really know how to test it either, but I've ran a few scripts I had and they all did fine.
I'm more than happy to set up a release branch once this is merged in and see if we can get people testing for it, we usually give 3-4 weeks of time so at least 3 people can get in and test it. If newer changes in RST aren't in their develop branch/decided upon by that time we can always do a patch release after for a quick change.
We should also think about master->main at this time too and changing the default branch to develop.
|
Okay, thanks for that! I've been using the master and develop branches all over the place too so I'm confident in their reliability. It would be great if you could set up a release branch, I will definitely help out with testing for it. I support the other changes to, with master to main and changing the default branch. |
|
Okay because this is a fairly benign PR (just bringing the features of master into develop) I'm going to go ahead with it. Then we can move forward with the rest of the changes proposed by @carleyjmartin . |
Scope
Merging master back into develop as several PRs were made directly into master preceding v1.1.1 release.
Approval
Number of approvals: 2
Test
I'm not sure what really needs to be tested here. The main differences that master has compared to develop are:
All of these changes were tested prior to release v1.1.1.
I was responsible for the improper workflow before, where PRs #32 #34 #35 were made directly into master. Luckily, this hasn't affected development very much, but still should be rectified.