bump: version 0.2.0 → 1.0.0

[kenibrewer]

Description

v1.0.0 release of pycytominer

The changelog was initially generated with cz bump --files-only but was manually edited to add the changes that pre-dated adoption of the conventional commit standard.
The changes added to the changelog are summaries of changes relevant to users and key dev processes rather than all changes.

Closes #330

Checklist

Please ensure that all boxes are checked before indicating that a pull request is ready for review.

• I have read the CONTRIBUTING.md guidelines.
• My code follows the style guidelines of this project.
• I have performed a self-review of my own code.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.
• I have deleted all non-relevant text in this pull request template.

[kenibrewer]

@d33bs @gwaybio I would particular appreciate feedback on the changelog in case there's any important changes relevant to users that I missed.

[codecov-commenter]

Codecov Report

Merging #348 (c89d651) into main (ea789ba) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #348   +/-   ##
=======================================
  Coverage   95.62%   95.62%           
=======================================
  Files          56       56           
  Lines        3135     3135           
=======================================
  Hits         2998     2998           
  Misses        137      137           

Flag	Coverage Δ
unittests	95.62% <ø> (ø)

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

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[d33bs]

Woohoo, v1.0.0! I left a comment which may be way off-base (apologies if so).

Additional considerations:

• Clarifying for Version 1 release #330 closure: is step 2 accounted for? Mostly here this is a double check that we didn't need to cover more than the poetry build for PyPI / etc.

2. Minting a release which should be built automatically

• I recognize it might be forthcoming but wanted to double check on Doc: Add section describing bump and release process #343. Would it make sense to add some material to this PR? Otherwise would a merge now mean the release docs material is technically a part of the next release and not this one?

[kenibrewer]

• Clarifying for Version 1 release #330 closure: is step 2 accounted for? Mostly here this is a double check that we didn't need to cover more than the poetry build for PyPI / etc.

2. Minting a release which should be built automatically

Step 2 is accounted for and should happen automatically after drafting the new release.

• I recognize it might be forthcoming but wanted to double check on Doc: Add section describing bump and release process #343. Would it make sense to add some material to this PR? Otherwise would a merge now mean the release docs material is technically a part of the next release and not this one?

I threw together a quick release guide (based on my anticipated next steps).
My view is that documentation-only changes don't really need to be attached to a release (commitizen excludes docs changes from the CHANGELOG by default).
So if we need to make some tweaks to the release guide I don't think we need to worry about whether that's considered this release or the next.

[gwaybio]

@d33bs - are you able to give this a final look and approval when you're happy? It would be great for you to give this another look if you're able!

[kenibrewer]

@gwaybio @d33bs This is ready for re-review. I fixed the problems with the docs build (and an additional problem with the docs version showing as 0.0.0).

[d33bs]

Thank you for the replies to the comments! I've added a few more thoughts to this review for your consideration.

[kenibrewer]

@d33bs This ready for review again. I've moved some of the changes you had questions about into separate branches that we can discuss after v1.0.0 release.

[d33bs]

Thank you @kenibrewer !