Support for CLIMADA V6 after V7's release

[ChrisFairless]

In our own projects and amongst the partners we work with we expect that the adoption of CLIMADA v7 will be slow, mostly due to established workflows, training materials and a slow rate of change outside of academia.

Is there an opportunity to maintain a "legacy" branch of CLIMADA where users still working with the old measures and cost-benefit modules can submit bugfixes and patches?

I realise this is extra overhead for the team who will need to approve the PRs. Hopefully it's only one or two PRs per year submitted by the people who need them (realistically, that's mostly me). We wouldn't keep Petals compatibility, and we'd probably only provide it until something in the dependencies breaks.

If we were to go ahead with this, I don't know how we would manage releases:

• Simplest is not to do releases and just have an ongoing branch. Anyone who wants to use it checks it out, and anyone who wants to contribute submits a pull request to the branch
• More complex would be to maintain an occasional release cycle where the semantic version number is updated and a new version is published to pip. This would be ideal ... but I haven't a clue how much work that creates. It would be great if users still working with older functionality wouldn't have to learn how to install CLIMADA by cloning the repo. @emanuel-schmid maybe you can advise on this.

It's also worth noting — maybe this won't be required at all. Maybe there aren't important enough fixes to warrant this. But I'd like to know in advance if it's possible. Thanks!

[chahank]

The simplest I think is for your team to maintain a branch which satisfies the requirements. This would mean no conda / pip release though. I do not see a scenario where we start maintaining diverging versions.

Another important option would be for your team to develop "migration" scripts that allow users to easily transfer from code developed with older version to the V7.

[ChrisFairless]

OK thanks! Yes, we can maintain that as and when it becomes necessary, and try to support users in installing from the branch.

Building migrations scripts will be possible, though easier might just be instructions on copying between Excel files, since they'll be aimed at people who are creating the inputs rather than writing code.

Side note: we know that we need to propose new Excel input templates and IO code for v7. We'll do that ... when we do that. It might be for v7.1, we'll see.

[chahank]

Great!

Yes, we can work on the Excel input as soon as the new approach is ready. The ambitious timeline is for the summer. Part of the functionalities have already been merged, but the main changes to the cost benefit will come last.

[emanuel-schmid]

Apart from the extra work I see no reason not to do patch releases on former versions of climada.

Depending on the amount of work, i.e. the number of patches to be applied and how difficult it turns out to keep the dependencies in check, I'm quite happy to release them to pypi and conda-forge.

On the other hand I'm not all too happy with the idea of another develop branch as that sounds like a spring of entropy to me.

Instead I'd rather have a release branch like, e.g. release-6.1, where nothing happens except merge requests for patch releases; and when they are accepted, channel releases are triggered immediately.

Bottom line: fine with me but only bug fixes and patches, no additional features.
I hope that's fine with you too @ChrisFairless

[ChrisFairless]

That sounds perfect actually. It doesn't make sense to do more than bugfixes and I agree with avoiding a second develop branch. And as soon as something remotely difficult breaks, we can withdraw support and tell people it's time to move to v7.