Release cycling

[iameskild]

Given that we just released v0.4.0, this would be a great time to focus on how we can improve the release cycle process. As @tonyfast pointed out in a recent QHub sync, we improved the back half of the release process (ie pre-releases) but we have work to do on the front half (which would be now if we are thinking about the next release). Below is a first draft of a proposed end-to-end Release Cycle.

Release Cycle

Starting point - a new release is out

• Create milestone for post-fix release
  • Reserved for
    • minor bug fixes that don't impact API surface
    • minor doc / release note updates
  • Testing requirements
    • relying on integration tests should be sufficient
    • ensure specific bug is actually resolved
  • Cut post-fix release as soon as bugs/docs are fixed

Looking forward

• Create milestone for next release
  • What kind of release is this?
    • Major, minor, patch?
  • Triage the larger bugs that should be addressed in this release
  • What new features, if any, will be included in this release?

Pre-release process

• Based on release milestone, what issues / features are outstanding?
  • What are the priorities?
  • What can be moved to the next release?
• Plan release and announce build freeze
  • Test and fix bugs
  • Cut Release-Candidate
  • End-user validation
    • Perhaps it would be nice to schedule out a long call and invite anyone who is interested in end-user testing, general qhub tutorials, etc. ??
  • (Repeat steps if necessary)
• When the release is ready
  • Update release notes
  • Cut official release
  • Validate release is available on PyPI and Conda-Forge

[iameskild]

This is a high-level summary of some thoughts shared by the team earlier today

Based on the PEP 440 post releases section:

The use of post-releases to publish maintenance releases containing actual bug fixes is strongly discouraged.
In general, it is better to use a longer release number and increment the final component for each maintenance release.

At this point, it might make sense to reserve post-releases for:

• updates to the release notes
• critical security related bug fixes

Going forward, we should consider being prepared to release a point release with any important bug fixes soon after we release a major or minor release.

[pavithraes]

We now have a release process documented here: https://www.nebari.dev/docs/community/maintainers/release-process-branching-strategy

Closing this discussion as resolved. :)