Versioning management about chia-docker HOT 5 CLOSED

Using ghcr.io/chia-network/chia:latest set up today, I'm getting version=1.1.4.dev0...would've expected 1.1.5.

from chia-docker.

Well, there's some progress, as there are since yesterday two distinct tags, resp. 1.1.6 and latest.
Unluckily, I pulled both, and in both cases the output of 'chia version' in the container console is 1.1.7.dev0. I was previously with a full node in 1.1.5 and the harvester in the container in 1.1.6.dev0, now it's 1.1.6 and 1.1.7.dev0 resp.
It seems to work for now, but the build process has definitely to be sorted out before this kind of heterogeneous setup raises major issues. I'm particularly thinking of the next major version including the pool protocol, where we can anticipate a harvester with the pool protocol and a full node without it (or vice versa ...) will very probably not dialog together very well !

from chia-docker.

from chia-docker.

Perhaps there can be a tag for the latest stable version and a separate tag for the version in development? I don't imagine there's significant enthusiasm for reconfiguring docker-compose etc every time the version number changes...
…
On Sun, 23 May 2021, 2:59 am Gnomuz, @.***> wrote: Well, there's some progress, as there are since yesterday two distinct tags, resp. 1.1.6 and latest. Unluckily, I pulled both, and in both cases the output of 'chia version' in the container console is 1.1.7.dev0. I was previously with a full node in 1.1.5 and the harvester in the container in 1.1.6.dev0, now it's 1.1.6 and 1.1.7.dev0 resp. It seems to work for now, but the build process has definitely to be sorted out before this kind of heterogeneous setup raises major issues. I'm particularly thinking of the next major version including the pool protocol, where we can anticipate a harvester with the pool protocol and a full node without it (or vice versa ...) will very probably not dialog together very well ! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#51 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRYZ4GXRBF6KNMM6BCGLQDTO7PHTANCNFSM44XB3MOQ .

Agreed that version management is always a big task, esp. in the early stages of a project. But for now, I even can't understand the logic behind what's being done.

Your suggestion does make sense :

• the 'latest' tag should pull the latest stable version, with a tag for each of the N (tbd) previous released version. As of now, 'latest' should pull 1.1.6 (and not 1.1.7.dev0 !), and the other explicit tags for the released versions should be '1.1.6', '1.1.5', '1.1.4', ...
• there should also exist a '1.1.7.dev0' tag pulling the matching version for those willing to test the version under development, and maybe a generic 'dev', 'testing' or whatever tag pulling the latest dev version. That will be particularly necessary with the future pool-compatible version, where intensive testing will have to be done on testnet. The challenge on this one is the build frequency of the image against the main repo, esp. for those like me with a distributed architecture mixing a baremetal farmer and a harvester running inside a docker container.

These are just proposals, there are certainly many other solutions, and I clearly don't have to a full view on their implications in terms of repo & versioning management vs docker image building. But whatever the dev team chooses, it now has to be decided and documented so that we all know what version we pull when using such or such tag.

from chia-docker.

the versions that do not match the expected "latest" are because of a known bug with git submodules. Its unfortunate, but I assure you its the right version of the software.

from chia-docker.