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 withutopya
still included. - Provide fixes to the most serious bugs to
v1
(if not feasible, we could also call itv1-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 patchesv1.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?