Naming convention OpenVario images

[August2111]

In the last few days/weeks I have created a lot of images. Unfortunately, the current name doesn't give me a real picture of which firmware version of the OpenVario package is actually being used - the number of the day ('22019') is very meaningless (you can also use a very old version on this day have built)... A bad side effect of the previous name is the length: In no file explorer you can see the configuration used and the build tag right away. The word 'openvario' is written out 3 times - really completely pointless

My suggestion for a new naming convention:

• Git branch versioning (using tags): The tag should be derived from the Yocto version used (e.g. Warrior = 2.7, Hardknott = 3.3, Honister = 3.4...) - and count up the order as a subminor value. The first release from the beginning of January 2022 corresponds to a version 3.3.1 (1st release with Hardknott) - and the next release to 3.3.2. However, the preliminary releases are also taken into account!).
  Self-built images get a 7-digit commit number at the end.

• Even this is not solved if the developer changes the configuration and the files independently, but you get an impression of the development status from which it was derived! All other significant changes should also be written into a config file that can be found in the root of the SD card: XCSoar version, sensord version, variod version, etc. etc.

• The image name should be as short and meaningful as possible - and possible redundancies should be removed, no 'normal' user needs 'rootfs' for example - this may only be of interest to the developer - and he in turn knows how he built the image!

• The device type should also be more meaningful, in my opinion 4 characters are enough: 2 for the display and 2 for the size, e.g.

  • ch70 = openvario-7-CH070, OV with CheFree (Texim) 7" display
  • pq70 = openvario-7-PQ070, OV with Pixel Qi 7" display
  • am70-2 = openvario-7-AM070-DS2, OV with Ampire 7" display and the DS2 sensor board
  • ch57 = openvario-57-lvds, OV with CheFree (Texim) 5.7" display
  • am43 = openvario-43-rgb, OV with Ampire 4.3" display

• The lowercase letters in the MACHINE type prevent some Yocto build warnings

This would make the names of the images much shorter and describe the actual configuration much better!
'OV-ch70-v3.3.2.img.gz' or with commit 'OV-ch70-v3.3.2-73fbee0.img.gz' instead of 'OpenVario-linux-openvario-image-glibc-ipk-22005-openvario-7-CH070.rootfs.img.gz'

If important information about the image type is missing, this would be the opportunity to integrate it. But while we're in the process of cleaning up the whole process, it would also be the right time to make that switch now!

[kedder]

This all makes sense to me. I can only suggest using git describe for version numbers - from my experience it produces pretty unique and descriptive version numbers.

[linuxianer99]

I also agree, that the image name is a bit overkill ;-)
This is the default name, yocto creates, so nobody adapted it.

I am also not happy with the Year-day versioninig ... it was a good idea at the start ...

The version number with the increasing minor at the end, makes me a bit nervous. It has nothing to do with the yocto release number. So we are combining the yocto version 3.3 with a OV specific number .1. In my mind, I would be better to split these numbers ...

OV-ch70-v3.3-rel2.img.gz

This shows clear, that this release is yocto 3.3 and Openvario release 2.

I am also not happy with the DS2 variant. Maybe we can combine them ?

[kedder]

Do we actually care what yocto version the image is based on? I feel this is an internal implementation detail, doesn't necessary has to be exposed on version numbers.

[linuxianer99]

You are right. We can also put it in he list of "contained software components" ...

[linuxianer99]

Btw.
i am working on an automated build / release process right now.
Think we have also to discuss the storage of the released files ...

I suggest creating release notes at the meta-openvario repo, but building the release at the ov-build repo.
As meta-openvario contains not the whole image, this makes more sense ... and also simplifies the automation a lot ;-)

[August2111]

OV-ch70-v3.3-rel2.img.gz

sounds also good for me

Do we actually care what yocto version the image is based on? I feel this is an internal implementation detail, doesn't necessary has to be exposed on version numbers.

The (version) number inside don't care to yocto, this is a proposal to make a git tag for meta-openvario based on a the current status. So it is very easy to know which basic components are in, only with the name...
My main point is the version tagging - and the names for this - and how to create a meaningful number

Think we have also to discuss the storage of the released files ...

But let us concentrate here on the 'naming convention' - and this in a new discussion round?

[August2111]

I also forgot the hardware platform: This should of course also be included in the image name - i.e. whether the image was built for CB2, CB1, RPI3, RPI4,...! So my suggestion now:

• OV-CB2-ch70-v3.3-rel2.img.gz or
• OV-CB2-ch70-v3.3.2.img.gz or all with lower case
• ov-cb2-ch70-v3.3.2.img.gz

[August2111]

Of course you are right - until now! But you should also think about a change here: The previous MACHINE names do not take such a change into account, are forever long with double information (openvario-7-CH070) contains 2 times the display size 7", the names are inconsistent ("57-lvds " and "43-rgb" do not match the others) - and produce a lot of warnings during the build due to the capital letters...
From my point of view, this also belongs in a better and clearer setup!

[linuxianer99]

That's all right ... We started with 7 lvds and 4,3rgb ... After a while there where other 7" variants ... that's the reason for all the inconsistent naming ...
The only thing I say, not change each and every thing in one step .... This are all breaking changes ... so we should do them carefully and well documented ...

[MaxKellermann]

I think having different machine types (and a different image) just because somebody attached a different display is too complicated for everybody; for OV developers and for users. You don't install a different Windows version if you plug in a different monitor, do you?

Of course, the ARM world is different from x86, much needs to be hard-coded in DeviceTrees instead, less plug'n'play. But there must be a better solution than creating a machine type for every display setup.

Bottom line: at most one image per board type; I'd even go as far as having only one image for all CubieBoard revisions, and one image for all Raspberries. Remember, Raspbian has only one image for all revisions!

To accomodate for different displays, the first boot should be done with a conservative configuration, where the user can choose of many different board/display configurations; maybe even from within u-boot. Save the choice to a u-boot env file, and the next boot is fully-featured.

Right now, there are several copies of the display resolution; how complex and fragile! There should only be one copy, to be used by everybody.

[mihu-ov]

I don´t think there is a conservative configuration that covers different LCDs attached to the CB. Maybe we could have a config file where one uncomments the correct device tree file to be used?

[August2111]

That would be the best solution if there were only one image per board type - and the display type was set via a configuration file. So you could end up going from one OV to another with an SD card (if you do the fiddly work). It seems more difficult to me to cover the different sensor board types in a similar way!

[linuxianer99]

So what is the consence of this version number now ??

Should we name the tags like yocto + release number ??

3.3-1
3.3-2

Or should we start a complete different scheme, ignoring the yocto build ?

[kedder]

I would suggest to ignore yocto version numbers - they have their release numbers, we have ours. Yocto versions doesn't mean much to users and new yocto releases doesn't necessary result in any visible changes to OV users. I'd suggest start from 2.0 (or 3.0 to make it look highter than 21118) and start from there.

[linuxianer99]

ok.
Lets make a tag called 3.0.

For the release we will count up 3.1 ... 3.2 and so on.
For the nightly we can have 3.0-<number of commits since 3.0>-: 3.0-1-e53472a for example

[linuxianer99]

@MaxKellermann : I tried to integrate the output of "git describe" into the DISTRO_VERSION variable, but with no success. Do you have an idea for this ?

[linuxianer99]

Hey All,
i did some testing with the version numbers .. Here the result:

For a stable build with a tagged github commit:
ov-3.0.0-openvario-57-lvds.rootfs.img.gz

For a testing build, based on a tag but with one commit ahead:
ov-testing-3.0.0-1-ga7d5c2d-dirty-openvario-57-lvds.rootfs.img.gz

Think we should think about the machines topic in the next step, but if it looks ok, i will create a PR with this change ...

@August2111 @kedder @MaxKellermann @mihu-ov
What is your opinion ?

[linuxianer99]

@kedder How should the filename look like ?? Can you make an exmaple please ?

[August2111]

And I don't like the day numbering so much: It says nothing about the content, when the project is pulled or merged - it gives only a hint about the day, when it is compiled and built...

In the past that was the only way to distinguish the images - and in the future that should take over the version number, with a new patch number every time. I already have - only internally! - started with it and I've already reached patch 4 ;-) If it starts again from '0', I can live with it, but in the end I have to explain more than necessary ;-(

I also don't like that we don't cut the old braid with the machine names, they just don't match (f.e. openvario-57-lvds vs. openvario-7-CH070) and from my point of view they make the names longer than necessary (quite bloated)...
I understood Max in such a way that we should even build only one version for all derivatives and distinguish between them via a config file... But unfortunately that's not that far yet, there's still a lot of work to be done ;-(
Nevertheless, I think that it would be better to use a short, comparable name in the image than to gradually subject the name to constant change - that really confuses our users...

But that's my personal opinion, which probably also results from the fact that I'm new here - and it seems difficult to me even among the 5 of us to set up a uniform, short name structure!

I had already made my suggestions, but what comes out now is unfortunately only a half-hearted result in my opinion...

[linuxianer99]

And I don't like the day numbering so much: It says nothing about the content, when the project is pulled or merged - it gives only a hint about the day, when it is compiled and built...

In the past that was the only way to distinguish the images - and in the future that should take over the version number, with a new patch number every time. I already have - only internally! - started with it and I've already reached patch 4 ;-) If it starts again from '0', I can live with it, but in the end I have to explain more than necessary ;-(

I also don't like that we don't cut the old braid with the machine names, they just don't match (f.e. openvario-57-lvds vs. openvario-7-CH070) and from my point of view they make the names longer than necessary (quite bloated)... I understood Max in such a way that we should even build only one version for all derivatives and distinguish between them via a config file... But unfortunately that's not that far yet, there's still a lot of work to be done ;-( Nevertheless, I think that it would be better to use a short, comparable name in the image than to gradually subject the name to constant change - that really confuses our users...

But that's my personal opinion, which probably also results from the fact that I'm new here - and it seems difficult to me even among the 5 of us to set up a uniform, short name structure!

I had already made my suggestions, but what comes out now is unfortunately only a half-hearted result in my opinion...

@August2111 I already stated, that this is just the first change and that we will continue with the machine names later on ... There is big impact, if we change these, so i don't want to break anything ...
Sorry for my "incomplete" proposal ... maybe you can do the work at once, if you are not satisfied with my proposal ....

[linuxianer99]

So i eliminated the "rootfs" as well now ...
The git describe command brings the

ov-[testing-]      =>   Basename (constant string)  suffix -testing for testing builds
3.0.0-                 =>   latest git tag in source
1-ga7d5c2d-dirty-  => number of commits from latest git tag + commit hash + dirty, if there are still changes after the latest commit
openvario-57-lvds  => Machine name

In my point of view, the new name is fine and also matches @August2111 proposal. The only thing missing is the rename of the machines. if this is done, the name will automatically be correct. @August2111 That was the fact i was talking about in my last post ...

Before we change the machine names, we should also think about the DS2 differences ....
The only difference is an enabled UART:

3a4
>     compatible = "panel-lvds";
7d7
<
26,28c26,28
< // UART5 on Schematic
< &uart5 {
<     pinctrl-0 = <&uart5_pi_pins>;
---
> &uart5_ph_pins {
>       pins = "PI10", "PH7";
>       function = "uart5";

So we should eliminate these variants too !

[kedder]

I have nothing against this suggested versioning scheme. I'd suggest to use whatever git describe produces for the version number. Seems to work well in practice.

[linuxianer99]

So i will change the image name in the next pre-release like:

ov-3.0.0-2-g1fba4bd-dirty-openvario-57-lvds.img.gz

Fine for all ??