Prepare 1.0.0b1 release

[mtreinish]

Summary

This commit changes the version strings from 1.0.0 to 1.0.0pre1 in preparation for tagging the 1.0.0pre1 release. After the tag we should switch the version number back to continue developing the 1.0.0 release series as we approach the actual release.

Details and comments

[mtreinish]

We probably want to wait for Qiskit/qiskit-bot#43 to merge and be deployed before we move ahead with this.

[coveralls]

Pull Request Test Coverage Report for Build 7051797779

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 16 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-0.02%) to 87.431%

---

Files with Coverage Reduction	New Missed Lines	%
crates/qasm2/src/expr.rs	1	93.76%
crates/qasm2/src/lex.rs	3	91.41%
crates/qasm2/src/parse.rs	12	97.13%

Totals
Change from base Build 7049384648:	-0.02%
Covered Lines:	59818
Relevant Lines:	68417

---

💛 - Coveralls

[mtreinish]

We hit a snag using pre1 one as PEP440 calls for pre1 to be normalized to rc1 https://packaging.python.org/en/latest/specifications/version-specifiers/#normalization which would conflict with the eventual rc1 release. So I'll respin this PR to use 1.0.0b1 instead.

[jakelishman]

Just thinking: maybe we want to make this version-number bump on a separate semi-stable branch, just on the off-chance we need to make emergency post-release patches to the beta? It'd be a nuisance if we have to roll main forwards and backwards.

[jakelishman]

Huh, I actually should make the docs read this out of the package as part of the "single source of truth" for the versioning. I didn't think about that at the time.

[mtreinish]

Just thinking: maybe we want to make this version-number bump on a separate semi-stable branch, just on the off-chance we need to make emergency post-release patches to the beta? It'd be a nuisance if we have to roll main forwards and backwards.

I was really hoping for a one and done here. The preview release is just supposed to be a snapshot of the current state of the repo without any commitments. Aside from needing a post release to fix a packaging bug (the changes in packaging are the biggest concern for me with this release) which we'd hopefully catch immediately I can't think of any reason to do a 1.0.0b2

[mtreinish]

That being said if we do need to do a 1.0.0b2, it'll be simple enough to create a branch from the 1.0.0b1 tag. Or were you more just advocating that we create a beta branch from main and retarget this PR to that branch?

[jakelishman]

Nah, you're right - if it becomes necessary (and I hope it doesn't), let's just branch retrospectively from the tag.