Dependency management changes and release procedure

[je-cook]

Description of issue / requirement to address

As we start becoming more stable we should have a release cycle and adjust how we deal with dependencies.

Proposed solution

A release (not necessarily a full release eg 0.0.0a1) will happen every 6 weeks, immediately after which the new dependencies updates will be merged into develop. Dependency updates should be tracked in a separate a branch develop_dependencies that tracks develop. These new dependencies will run on the CI so that breakages are caught and fixed early. New dependencies should be merged in to develop every ~6 weeks creating a more stable environment for new features to be added.

First step is in #1068 separate out dependencies into their minimal areas the full list to first tag:

• [x] Create a 'pinned' extras section where some absolute limits on dependencies can be set (covered in #1068)
• [X] Create develop_dependencies branch
• [x] Modify dependabot config (#1088 )
  • Remove all pinning
  • Change target branch to develop_dependencies
• [x] Create release workflow document (rst in docs or md in repo?) (~#1089~ #1126)
• [x] Make and tag first alpha release

Near Future:

• [x] Create docker container on 22.04 (without conda)
  • [x] Use pyenv so we can have a specific python version (#1102)
    • Release container will have releases deps
  • ~Add layer for develop on top of release container that pulls in dependency updates~
• [x] Create docker compose file
  • Contains all the flags for getting gui etc working
  • Document compose file eg how to pipe in current develop git repo
• [x] Shrink docker container
  • Remove unneeded build/source directories etc.

In a couple of cycles:

• [x] Update to use the LTS python (3.10) and remove pyenv (#701)
  • ~Awaiting Coolprop and numba-scipy updates~ Coolprop for the amount we use it has a dev version for now, numba-scipy has been updated

The docker containers are just awaiting our conversion to dolfinx

• [ ] Fenics to Fenicsx conversion (#751, #1509)

Alternative solutions

Live with unstableness and never release

Additional context

We need a nice workflow in order for everyone to be able to improve the code while not being disrupted too often

[hsaunders1904]

Seems a good plan to me. I think it will be really good to get into a development cycle.

Excuse the brain dump, but these are a few thoughts I had:

• Now we have some dev schedule, we could discuss making a "sprint board" containing issues for those 6 weeks.
• Now we're going to start releasing versions, we should decide on a versioning strategy.
  • I'm assuming semantic. Do we stick with 0.0.1aX and increment X for the time being? When we do reach 0.1.0, do we increment the minor version every 6 weeks, or do we start incrementing alphas again?
• There's also some discussion to be had on what stance we take on bugfixes on old releases.
  • Will we backport bugfixes, or will we insist users use new minor/major versions?
  • This will influence our branching strategy, do we keep a branch alive for each minor release to apply bug fixes to?

Obviously none of this changes our current plan, but they're things we should think about.

[je-cook]

Good things to think about, here's my initial thoughts

I'm assuming semantic.

I think semantic makes more sense than calendar based probably but not wedded to that.

Do we stick with 0.0.1aX and increment X for the time being?

Yeah I think so. Once we have something we're happy with go straight to 0.1.0 and then point release every 6 weeks makes the most sense to me. We can always go back to alphas if we need to.

Will we backport bugfixes...?

I think bugfix backport releases probably shouldnt be needed until at least 0.2 (or maybe 1.0 onwards) at a minimum before that we should insist on the latest version being used. Maybe more widely thats a decision for after 1.1. I'm inclined to say latest minor version of a major version and then have v1, v2 branches whenever we get that far down the line.

[je-cook]

Fenicsx conversion will be done separately