Use a generic DOI site instead of 10.80507

[dchiquito]

10.80507 is our test DOI site, we need to support both that and our
production site, 10.48324.

[codecov]

Codecov Report

Merging #65 (c859d37) into master (2a7919e) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master      #65   +/-   ##
=======================================
  Coverage   96.07%   96.07%           
=======================================
  Files          13       13           
  Lines        1274     1274           
=======================================
  Hits         1224     1224           
  Misses         50       50           

Flag	Coverage Δ
unittests	96.07% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
dandischema/models.py	93.92% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2a7919e...c859d37. Read the comment docs.

[yarikoptic]

IIRC we already merged some breaking changes (newer version of schema) in master. I think this PR might be a waking call to establish a dedicated branch to accumulate breaking changes (eg 'next') while leaving master to be ready to be released any moment.

[satra]

@yarikoptic - yup - that's why i wanted to chat.

[yarikoptic]

What about:

• we initiate schema-next (so matches schema-<version> tags) branch off current master and push it here
• change base for improve help options #60 to be schema-next
• hard reset master to 4f6e708
• re-merge (some? all?) PRs some PRs merged since then but skip fix: clean up optional components of the schema #52 which boosted version (do only local testing)
• force-push reset master
• re-initiate tests for this PR to just make sure we are in clear
• merge PR/release without changes to schema version

gotchas might come in changelog generation after we do merge schema-next into master since we are per se not interested in that merge but rather in merges/PRs into that branch. I remember @jwodder investigated that abit awhile ago but I forgot what was the verdict.

[satra]

this PR will also require a schema version change, so before we implement a full blown refactor, we may try to cut a release to 0.5.0 with the other PR in tow before we fully implement validation against multiple schemas.