Add release procedure in CONTRIBUTING (#1039)

CONTRIBUTING.md

@@ -50,24 +50,25 @@ If you've never submitted a pull request before, it can take a little while to b
 
 * Create a [GitHub account](https://github.com/signup/free).
 
+* Fork whatever repository you plan to commit to by clicking on the "Fork" button at the upper-right of the home page.
+
 * If you plan to fix a bug, feel free to first report the bug as an issue on its own.
   In the text, you can mention whether you're planning on addressing it yourself.
-  *Pro tip*: if you do submit a pull request to fix it, put "Fixes #<issue number>" in the commit message and it will close automatically when your pull request is merged.
 
   If you're concerned your change might be controversial, you can also use an issue to propose your change in general terms and discuss it before implementation.
 
-* Fork whatever repository you plan to commit to by clicking on the "Fork" button at the upper-right of the home page.
-
 * If you haven't already implemented your changes, check the package out for development: hit `]` in the Julia REPL and then type (for example) `dev Images`.
 You'll get a copy of the full repository in your `~/.julia/dev` folder. See the [package manager documentation](https://julialang.github.io/Pkg.jl/v1/) for further details.
 
 * Make your changes. Generally you should be working on a branch, so your work doesn't conflict with ongoing development in the `master` branch. Ensure you follow the [Julia style guide](https://docs.julialang.org/en/v1/manual/style-guide/index.html) for your contribution.
 
 * Test your changes. We aspire to have test coverage for every bit of "user visible" functionality. Tests are stored, appropriately, in the `test/` folder of each package. You can run existing tests yourself and add new ones. Sometimes testing is more work than the actual change itself, but having tests ensures that no well-meaning future developer will accidentally mess up your functionality---it's worth it!  *"A fix is for today. A test is forever."*
 
+* *Pro tip*: if your change fixes a bug, put "Fixes #<issue number>" in the commit message and it will close automatically when your pull request is merged.
+
 * Submit your changes up to your fork and then submit a pull request---whoopee!
 
-* See what happens to the automated tests that run on Travis and/or AppVeyor. If there are errors, check the logs and see whether they look like they are related to your changes; if so, try to fix the problem by adding new commits to your pull request. Once the tests pass, hooray! :tada:
+* See what happens to the automated tests that run via GitHub Actions. If there are errors, check the logs and see whether they look like they are related to your changes; if so, try to fix the problem by adding new commits to your pull request. Once the tests pass, hooray! :tada:
 
 * Relax and wait for feedback. We try to review contributions quickly and courteously. But we are human, and sometimes we get busy with other things or fail to notice an email; if it's been a while since you submitted your pull request, try posting a polite reminder about the existence of your pull request.
 
@@ -77,6 +78,14 @@ You'll get a copy of the full repository in your `~/.julia/dev` folder. See the
 
 From the whole team, thanks in advance for your contribution!
 
+### Making a breaking release
+
+- delete the old tests in `test/deprecated.jl`
+- delete the code in `src/deprecations.jl` that is marked as being from the previous release (there should be a section marked, e.g., `## v0.26 deprecations`)
+- ensure that any new deprecations (including deprecated tests) are in place. Note that tests that generate depwarns should be in `test/deprecated.jl`, as these are skipped if `--depwarn=error`.
+- run the existing tests with `--depwarn=error` and check that tests pass. If they don't, consider running with `--depwarn=yes` and follow the hints about fixing the deprecations.
+- update NEWS.md
+
 ### Contribution tips
 
 * [Revise](https://github.com/timholy/Revise.jl) is a package that
@@ -88,5 +97,4 @@ your changes.
 * Debuggers can help you get to the root of a problem. There are many choices and interfaces:
   + [VSCode](https://code.visualstudio.com/docs/languages/julia#_debugging) has a polished GUI for debugging
   + [Debugger](https://github.com/JuliaDebug/Debugger.jl) has a polished command-line interface
-  + [Rebugger](https://github.com/timholy/Rebugger.jl) has an innovative but somewhat less-polished command-line interface
   + [Infiltrator](https://github.com/JuliaDebug/Infiltrator.jl) offers more limited debugging, but often it's precisely what you need while avoiding the performance penalties that some of the other options suffer from.

src/deprecations.jl

@@ -1,2 +1,6 @@
+## v0.26 deprecations
+
 @deprecate otsu_threshold(img::AbstractArray{T}, nbins::Int = 256) where {T<:Union{Gray,Real}} T(find_threshold(img, Otsu(); nbins))
 @deprecate yen_threshold(img::AbstractArray{T}, nbins::Int = 256) where {T<:Union{Gray,Real}} T(find_threshold(img, Yen(); nbins))
+
+## v0.27 deprecations