Branch strategy for AiiDA v2.0

[sphuber]

This is a discussion on what branching strategy to adopt for the upcoming v2.0 of aiida-core. Currently develop is at v1.5.2 and we have the v1.6.0 just around the corner. The only work directly for v2.0 that has been completed so far is the implementation of the new file repository which is almost ready to be merged. As far as I see it, there are two main approaches:

1. As soon as v1.6 is released and #4345 is ready to be merged, it is merged straight into develop, essentially making develop the upcoming v2.0 release. If there are any patches or features that need to be released before v2.0, the typical support branch strategy is used to make new releases.
2. As soon as v1.6 is released a release/2.0.0 branch is created and #4345 is merged into that branch, as well as all the other work that will follow that is slated for v2.0. During this period we can continue to merge fixes for v1.6 into develop and keep continue releasing as normal.

The advantage of the latter approach is that it is slightly more convenient to keep working on patches (and potentially features) for the v1.0 series, while the v2.0 work is being prepared. However, the downside is that the release/2.0.0 might become a long-lived branch that diverges from develop and merges will become more difficult over time. There is a risk that we run into a similar scenario as for the transition of v0.* to v1.0 with the engine reworking. The first approach makes this slightly easier, although one still has to make sure that the relevant parts of patch and feature releases on support branches are merged carefully back into develop. It also may bring a psychological advantage in that when develop mirrors the state of the future v2.0 it will push is more to work towards its release.

I think I am personally leaning towards option 1 and simply commit ourselves as a team to work as focused as possible towards the v2.0 release once the new file repository implementation is merged into develop. Let's discuss!

[greschd]

Hmm, to me this depends a bit on how "far out" 2.0 is. Of course it's difficult to predict exactly, but what's the current thinking on when 2.0 might be released?

Overall, I also tend to favor 1, but if 2.0 is still far out (say, >6 months) maybe 2 makes more sense.

[greschd]

Side question: Are we planning to include any other backwards-incompatible changes into 2.0?

[sphuber]

There is the milestone that we should use for this. Note that I created this a long time ago and added issues that were on my wish list to be addressed. These are of course up for discussion. In line with @giovannipizzi comment below, we should just decide once and for all what this milestone should include, estimate the timeline for it to be accomplished and then stick to it. I would personally definitely aim for v2.0 to be released within 6 months max.

[greschd]

Can we add a type/backwards-incompatible tag for the issues? I think that'll make it easier to decide if a particular issue needs to go into 2.0, or can be punted to 2.1.

[sphuber]

I have created the type and made a first pass of the issues that I am pretty sure should be labeled as such. I noticed also that there are quite a few issues in the milestone that will essentially be addressed by my new file repo PR. It is difficult to see which ones without being intimately familiar with them. Will think if I can come up with a label for that as well to indicate that they would be fixed by proxy.

[giovannipizzi]

Quick comments - If we go with strategy 1, I suggest that we also set a timeline for the release, with the idea that we accept that features (that we ideally would like to have in 2.0) are not ready by then, and will be postponed. I think having a clear and realistic timeline a good strategy anyway.

I would note also that if we're not sure, (I think) we could go with strategy 2 and convert to strategy 1 along the way (again, maybe with a clear milestone, in say 1/2 months, to switch to strategy 1 - which would benefit from the psychological advantage?).

I would personally favour this intermediate strategy for three reasons:

• we create a proper branch where we can continue improving on the work of Implement the new file repository #4345, with proper PRs etc, rather than continuing changing the commits in the PR (I think this is the goal anyway)
• we have time to investigate a few issues that are still there in Implement the new file repository #4345 (beside speed of the migration, that can be fixed also later: mostly there are a few warnings from SQLite on multithreading when running the engine - my main worry is that, if those are not simple things to fix but an issue with the design, we remain in a situation where we committed already to make 2.0 the next release, but we don't know how to redesign it).
• Also, this will allow us to stress-test the engine together with the new repo, something not done yet (I did some tests in Implement the new file repository #4345, but those were using earlier versions of the asyncio engine, so many failures might have originated from there and have been fixed meanwhile). In this way, we give us the possibility to spend a few weeks running with the new engine both in 1.6 and in 2.0 and check the differences.

[greschd]

Yeah, I think this middle way makes sense. In general, I think we should aim to keep develop in (or close to) a "release-ready" state. So if we need to do more stress-testing, it should be a separate branch.

Thinking plugin testing, I think we should add a build of the aiidateam/aiida-core docker images for that branch.

[sphuber]

I fully agree that stress testing is very important, especially with a change of this magnitude. That being said though, experience teaches that it is really difficult to get people to test a branch if it is not in develop. I have been asking this for months now and very few have actually responded to the call. I understand the inertia because it still requires checking out a new branch, migrating the database etc. But that is exactly why I think merging to develop is maybe the way to go as it will push people to start actually testing it. We can then indeed start to improve on it through the normal PR procedure instead of having to keep rebasing my PR.

my main worry is that, if those are not simple things to fix but an issue with the design, we remain in a situation where we committed already to make 2.0 the next release, but we don't know how to redesign it).

If worst comes to worst and we figure out that, after having merged it in develop, it needs a lot more work and we need develop to be back at 1.6.*, we can always rename develop to release/2.0.0 and restore develop to the latest commit on the support track.

Anyway, if we can get people to commit to help stress test the PR in a separate branch then that is all fine by me to go with the intermediate approach.