Repository navigation
Discussion: Changeing the container tags聽#167
Description
Activity
on the idea of using a number for the container as well, i totally agree.
However, i think using "packaging change" is not a good idea .Why ?
The tag should indicate the build that created the image (Where does this image comes from ?).
This involve two things : the commit and the build date.
We do not need to always use the full tag, but something like this :openvoxserver:[openvoxversion]-[branch]-[commitid]-[date]
This will allows us to test new versions and absolutly pin-point the build the image comes from. This helps for debugging for instance , old builds with faulty dependencies.
In addition, a signature would be great for good-measure but not a must.
Can you please explain why the actual version schema is difficult to use?
I first want to understand the "why do we need a new schema".- we encode two version in one tag at the moment:
$software-$container - this is not very SemVer friendly
- we dont do
8.14.1-v1.2.3release often or at all atm - they are clunky to use
- i got from Ben that some people are confused about this version tags at all
that's my thoughts on this atm
- we encode two version in one tag at the moment:
we also could turn it around and do it like in voxbox: prioritize the container version and only flag wich openvox version they incorporate
If possible, I would go for the same version pattern as we use it in voxbox.
This makes it more easy for users, as we have the same schema everywhere.- in voxbox it makes sense to focus on the container version because we bundle a lot of different tools
- in openvoxserver we mainly bundle only the openvoxserver itself, so it makes sense to focus on the bundled software
but if we change we would have tags like:
- 10.0.0-openvox8
- 10.0.1-openvox8.14.2
- 10.1.0-openvox9.0.0-beta
if this is okay for the people, we can do this here too. no hard feelings.
Hi 馃檵
I鈥檇 like to discuss the build-up of container tags. As they currently stand, they seem to be difficult to use. Therefore, I propose that we make some changes.
We primarily pin it to the software that is mainly bundled into the container. Therefore, the container version is identical to the openvoxserver version. Additionally, there is a
-<Number>like in rpm packages, where the counter increments whenever there are changes in the packaging, but not the software itself.Whatcha thinking about that?