Utopia versioning (and ways forward)

With !277 (merged), I think we need to discuss versioning of Utopia, mainly because there are a number of backwards-incompatible changes in the CLI and model evaluation and users may not be willing to migrate their plots or touch their setup in any way that may affect their workflows – which is totally understandable.

We haven't really discussed this, but I think that !277 (merged) is the way forward for Utopia: utopya is much easier to maintain in its outsourced form, which incurs benefits for Utopia. Also, this makes many capabilities of the wider Utopia project available to people who may not want to use the C++ backend but still want to benefit from all the frontend stuff.

Proposal

… as suggested below:

• Branch off v1 from the latest version of Utopia with utopya still included.
• Provide fixes to the most serious bugs to v1 (if not feasible, we could also call it v1-stale 🤔)
• Call Utopia with outsourced utopya "Version 2", but don't create any releases or tags. Continue with development as before.
• Add an update guide to migrate from v1 to v2.

Previous proposal (click to expand)

To balance the two, I would make the following proposal:

• Label the current version of Utopia as v1.0.0 and create a tagged release
• Add a v1.x release branch to which selected changes / bugfixes are cherry-picked and released as patches v1.x.y
• Label Utopia after !277 (merged) as v2.0.0 and create a tagged release
• Continue development on the main branch and increment versions according to semantic versioning

What do you think, @herdeanu @mackharald89 @peanutfun @tgaskin @JulianWeninger?