You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This will be very important once we start doing releases of the package. As we cannot go back and update a given release, it will be important to tie a particular version of pydrad to a particular version of HYDRAD that we know it will work with.
We can do this most easily by setting the hydrad_stripped_down function to clone from a specified commit hash that we know works (i.e. passes all tests) with pydrad. As new releases are made and there are additions to HYDRAD, we can update this commit hash.
We could keep the master branch always on the most recent HYDRAD commit hash and just set it on each release branch.
The text was updated successfully, but these errors were encountered:
There could be a kwarg to hydrad_stripped_down for specifying the commit hash to clone from to make this a bit more flexible.
I think the best way to proceed would be to do a major release for each new (breaking) version of HYDRAD and then to continue to backport bugfixes as needed. Again, every effort should be made to make things backwards compatible, but that won't always be possible/practical.
This will be very important once we start doing releases of the package. As we cannot go back and update a given release, it will be important to tie a particular version of pydrad to a particular version of HYDRAD that we know it will work with.
We can do this most easily by setting the
hydrad_stripped_down
function to clone from a specified commit hash that we know works (i.e. passes all tests) with pydrad. As new releases are made and there are additions to HYDRAD, we can update this commit hash.We could keep the master branch always on the most recent HYDRAD commit hash and just set it on each release branch.
The text was updated successfully, but these errors were encountered: