Rename `:soroban-dev` image variant to `:future`
leighmcculloch opened this issue · comments
I propose the :soroban-dev image variant be renamed to :future.
I'm not sure this was ever the original intention of the image variants, but overtime they've come to track different environments. The latest image tracks compatibility with pubnet. The testing image tracks compatibility with testnet. The soroban-dev image tracks compatibility with futurenet.
That last image is not intuitively named. I suggest we rename the image variant to future so there's some conceptual association.
Similarly, it might make sense to rename :latest to some name that indicates that it tracks pubnet. I would assume :latest implies bleeding edge/mainline
:latest is a special name in images. If no variant is specified then latest is pulled.
Why not :futurenet?
Originally I had wondered about naming it :preview because it was the preview releases we deployed to futurenet.
I'm a little uncertain about locking the tags into network names exactly. On the one hand that's naturally how folks need to engage with the image.
Maybe we can do this but a different way...
Folks have asked for version numbers for the image (cc @mollykarcher). We could do that and then have the network labels be aliases of the latest images that are compatible with the different networks. So something like this:
Quickstart's versioning would likely follow the same versioning scheme we discussed a couple months ago where it followed the major version of the protocol, then otherwise used minor and patch versions independent of its dependencies.
All three image variants are today released from the master branch at every commit. They use the latest version of "quickstart" with just different versions of software installed.
If we introduced v20/21 versioning onto quickstart we'd probably need to change that so that once v20 was released, changes to quickstart would target the next v21 release so as to preserve that prior version. Otherwise if we kept shipping changes to v20, that'd be pretty confusing. This could be good for stability. If we needed to release features or patch releases of software back onto quickstart that would need to be patch releases on prior releases. We'd just need to build some discipline and process around that. That wouldn't come for free.
For the sake of simplicity we might want to settle on a build-number instead of a minor/patch version, so that any commit on a branch causes a release still, like what we have.
I'm imagining branch management and releases looking something like the below, which will not be fun to setup and maintain.
I'll have more of a think of what we can do that's simpler to retain some of the simplicity benefits of what we have today. Thoughts appreciated.
Given the number of components and complexity of the image, I think the above is probably too much given the time we can spend on it. So I'm withdrawing that idea.
I'll back to advocating for the original idea of simply improving the names. If we want to add versions to give people a better "handle" for specific releases, I sugest we use a simple incrementing value based on commit count on the master branch. For example:
Why not :futurenet?
Revisiting this, mostly because we have testing that is used for testnet, and the imperfect connect is somewhat convenient in that we can say software is released for testing, and that's what is used on testnet, and software is released as a "future" release and it is used on futurenet.
@chadoh Wdyt? Do you think that's too problematic?
I think one of these names:
futurepreviewexperimental
I think that’s fair. I like future most out of those three.