Skip to content

ODC EP 013 datacube‐core 1.9 2.0 release process

Jump to bottom Edit New page
Paul Haesler edited this page Oct 5, 2023 · 3 revisions

Overview

With significant changes already underway for the 1.9.0 release in the develop-1.9 branch, and the impending requirement for a develop-2.0 branch, this is a proposed development plan/release process to hopefully get us through the oncoming storm.

Proposed By

Paul Haesler (@SpacemanPaul)

State

  • In draft
  • Under Discussion
  • In Progress
  • Completed
  • Rejected
  • Deferred

Motivation

Significant changes are already underway for the 1.9.0 release in the develop-1.9 branch, and the impending need for a develop-2.0 branch for EP-11, a more complex workflow for managing PRs and branches will be required.

Other release related changes can be discussed here.

Minimum supported Python versions

Currently we nominally support down to Python 3.8, but the most recent xarray and pyproj releases both only support down to Python 3.9, and security support for Python 3.8 just ended, so obviously we have to bump up at least a bit.

Python minor releases come out roughly annually, and get bug-fix releases for about 6 months, then security fix support until 5 years after first release:

3.9: released October 2020, security support to October 2024. 3.10: released October 2021, security support to October 2025. 3.11: released October 2022, security support to October 2026. 3.12: released October 2023, bug fix releases to April 2024, security fixes to October 2028.

New language features of note in each release:

3.9: Standard library timezone handling; dictionary merge operator; better type hints. 3.10: match/case statement; type union operator 3.11: Exception groups 3.12: More typehint improvements; Execution engine enhancements

I think we should drop support for 3.8 from the next 1.8.x release, and set the minimum to 3.10 for 1.9 and 2.0.

Shared development branches

develop: Development branch for 1.8.x series releases. develop-1.9: Development branch for 1.9.x series releases. develop-2.0: Development branch for 1.9.x series release (to be forked from develop-1.9)

Phase 1, pre-1.9.0 release

When making code changes that need to be applied to multiple shared branches, write your code for the lowest relevant shared branch first (i.e. develop before develop-1.9 and develop-1.9 before develop-2.0), then:

  1. Create a new branch from the next shared branch up.
  2. Cherry pick the squashed commit for the change, from the lower shared branch, into your new branch.
  3. Resolve conflicts, and port and as needed (IMPORTANT)
  4. Create a PR to merge your new branch into the higher shared branch.

Reviews and approvals required for merging PRs into both develop and develop-1.9.

Discipline on the develop-2.0 branch can be reduced to facilitate speedy development during the initial stages of EP-11 work, during this phase.

Outstanding requirements before 1.9.0 release

  • Database migration management for the postgis driver.
  • Configuration layer rewrite as per EP-10
  • Further performance tuning of spatial queries (e.g. fall back to fast dumb implementation for dumb queries)
  • Documentation updates

On 1.9.0 release

  • Rename develop to develop-1.8.
  • Rename develop-1.9 to develop.

1.8 branch gets only bugfix and/or security releases - no more new features (and a clear date to drop support).

2.0 release requirements and process

  • To be determined

Welcome to the Open Data Cube

Home

Clone this wiki locally