allow setuptools_scm to describe .dev tags off of release branches

[zacharyburnett]

analogous to spacetelescope/stdatamodels#583, which is confirmed working

Tasks

• If you have a specific reviewer in mind, tag them.
• add a build milestone, i.e. Build 12.0 (use the latest build if not sure)
• Does this PR change user-facing code / API? (if not, label with no-changelog-entry-needed)
  • write news fragment(s) in changes/: echo "changed something" > changes/<PR#>.<changetype>.rst (see changelog readme for instructions)
  • update or add relevant tests
  • update relevant docstrings and / or docs/ page
  • start a regression test and include a link to the running job (click here for instructions)
    • Do truth files need to be updated ("okified")?
      • after the reviewer has approved these changes, run okify_regtests to update the truth files
• if a JIRA ticket exists, make sure it is resolved properly

[braingram]

Thanks! LGTM this is contained in a pip install of the current commit:

Successfully installed jwst-1.20.0.dev372+gf9c57728c

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.62%. Comparing base (efa4b47) to head (f9c5772).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9823      +/-   ##
==========================================
- Coverage   82.73%   82.62%   -0.11%     
==========================================
  Files         365      366       +1     
  Lines       37324    37529     +205     
==========================================
+ Hits        30881    31010     +129     
- Misses       6443     6519      +76     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[pllim]

Why are we tagging dev tags in release branches?

[zacharyburnett]

Why are we tagging dev tags in release branches?

not on the release branches themselves, but this setting reads the release branches for existing release tags and builds the .dev version off of that