Specify how to handle version submitted in maintainer guide

[NickleDave]

From discussion with @lwasser in Slack, related to confusion from at least one maintainer asking reviewers to review code that was not published on an index yet (not me doing such a thing 😳)

we should have very clear language in the guide that tells authors / maintainers they should release something just before submission. For new packages: a version 0.1. For existing packages, a patch release, e.g. if they made any changes related to a pre-submission issue or even changes in response to editor checks on the submission itself

yes - let’s add language to our author/ maintainer guide following what you wrote above. i think ideally the version submitted has a release - that makes it much easier to track changes to the package through our review. and i think publishing to pypi / conda prior to review could be highly encouraged but if they need help with that we could help them.

So in guide for maintainers, state:

• [ ] if the package has no version yet, release a version 0.1 before submission
• [ ] if changes are made in response to presubmission inquiry and/or editor feedback during initial checks, release an additional patch version and update the submission with this patch version

[NickleDave]

The question of which version to review came up here too:
https://github.com/pyOpenSci/software-submission/issues/84#issuecomment-1491465856

My understanding is we want the metadata to capture the exact version at time of submission.

• [ ] Is that correct?
• [ ] If so should we explicitly state it in the guide? I don't think we do

There's also a question of how to balance needs of reviewers with needs of a maintainers developing a package that's being actively used, who may need to squeeze in development time and/or fixes for uses whenever they can (like, in the middle of a review).