Eliminate git sha from version in case of release

[AAndrisa]

PR Description

In order to introduce the packages of libiio in a package repo the git sha was eliminated from patch value of the version variable and replaced with 0.
This flow is particular to a release build and is set by setting an environment variable called IS_RELEASE. If the variable is not initialized then the build will remain the same.

PR Type

• Bug fix (a change that fixes an issue)
• New feature (a change that adds new functionality)
• Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• I have conducted a self-review of my own code changes
• I have commented new code, particulary complex or unclear areas
• I have checked that I did not intoduced new warnings or errors (CI output)
• I have checked that components that use libiio did not get broken
• I have updated the documentation accordingly (GitHub Pages, READMEs, etc)

[AAndrisa]

Should this changes be implemented also on libiio-v0 branch for possible releases from that branch?

[rgetz]

I'm not sure this is a great idea - since it will not be set to "0" all the time - and users reporting errors will no longer know what version of iiod they are using - something from main, or a release. with the git version - everyone knew.

[SRaus]

For development propose and using it in other CI pipelines (like libad9361/9166, iio-osc etc), it's ok to keep using git_sha as patch version. Those daily-created packages are not used so often by customers.
For released versions, we are not allowed to use it anymore - released packages are added now in ADI Linux Package Repository and they need to have a number as patch version.

[AAndrisa]

I'm not sure this is a great idea - since it will not be set to "0" all the time - and users reporting errors will no longer know what version of iiod they are using - something from main, or a release. with the git version - everyone knew.

If the build will be from main the git sha will appear as expected.

[rgetz]

Then this is even worse - since sometimes a variable called "patch" is a githash, and sometimes it's not.

[rgetz]

Should this changes be implemented also on libiio-v0 branch for possible releases from that branch?

Absolutely not.

This is not a fix or a bug - so it doesn't go on the -v0 branch.

[rgetz]

To do things properly - I think there are many more changes required (and to keep backwards compatibility).

For example - deep in the context xml - it's called : "version-git" - I think we should leave it like that.

Packaging in the package managers needs to be done by each distribution - while we should make it easy for them to refer to something as a patch number - I don't think we need to abandon using git tags. They are invaluable when doing remote debug.

[SRaus]

To do things properly - I think there are many more changes required (and to keep backwards compatibility).

For example - deep in the context xml - it's called : "version-git" - I think we should leave it like that.

Packaging in the package managers needs to be done by each distribution - while we should make it easy for them to refer to something as a patch number - I don't think we need to abandon using git tags. They are invaluable when doing remote debug.

We do not abandon using git_sha. They will still be used for daily builds. But for releases will use .0 as patch version. In this case, there will be a release tag, bind to a commit, so debuggability will be the same. The reason behind is that packages will be added in ADI Package repository (for multiple distributions) and keeping git_sha in name will mess up versions.

[SRaus]

The new guidelines recommends that for all general available packages to indicate its level of stability in its name, by using tags like *_dev - Development / *_a - Alpha / *_b - Beta / *_rc - Release Candidate etc. We have not applied them yet for lib-iio, but probably we'll add _dev for non-released ones and _rc whenever we start testing a release.

[SRaus]

Should this changes be implemented also on libiio-v0 branch for possible releases from that branch?

Absolutely not.

This is not a fix or a bug - so it doesn't go on the -v0 branch.

There is in plan to create one more release for v0 - v0.26.0. In order to add it in a linux package repo, the guideline is to have patch version as a digit/number, and not git_sha.

[rgetz]

Should this changes be implemented also on libiio-v0 branch for possible releases from that branch?

Absolutely not.
This is not a fix or a bug - so it doesn't go on the -v0 branch.

There is in plan to create one more release for v0 - v0.26.0. In order to add it in a linux package repo, the guideline is to have patch version as a digit/number, and not git_sha.

like I said - this is not a fix or a bug - please do not do that.

I have no idea what "guideline" you are talking about.

Semantic Versioning - has been out for a long time (Dec 14, 2009) - for libiio - we actively decided NOT to use it. It wasn't an accident or by mistake that we decided to use githash - we decided that would be the better/easier thing to do.

Even in terms of Sematic versioning - you increment MINOR version when you add functionality in a backward compatible manner. Since dropping githash would break things - that's the definition of not backwards compatible.

[rgetz]

We do not abandon using git_sha. They will still be used for daily builds.

have a look at the current patch set - it will not be used for daily builds.

	IIO_INFO("Starting IIO Daemon version %u.%u.%s\n",
		 LIBIIO_VERSION_MAJOR, LIBIIO_VERSION_MINOR,
-		 LIBIIO_VERSION_GIT);
+		 LIBIIO_VERSION_PATCH);

changes it for all builds, including daily.

[AAndrisa]

We do not abandon using git_sha. They will still be used for daily builds.

have a look at the current patch set - it will not be used for daily builds.

	IIO_INFO("Starting IIO Daemon version %u.%u.%s\n",
		 LIBIIO_VERSION_MAJOR, LIBIIO_VERSION_MINOR,
-		 LIBIIO_VERSION_GIT);
+		 LIBIIO_VERSION_PATCH);

changes it for all builds, including daily.

The patch for daily builds won't be 0 because the variable LIBIIO_VERSION_PATCH is initialized with LIBIIO_VERSION_GIT in case of daily build

libiio/CMakeLists.txt

Line 375 in 7b407c4

if (NOT IS_RELEASE_ENV)

[nunojsa]

Here it goes my 2 cents on this...

like I said - this is not a fix or a bug - please do not do that.

I totally agree with this. Completely unnecessary IMO and just risking unnecessary trouble...

Semantic Versioning - has been out for a long time (Dec 14, 2009) - for libiio - we actively decided NOT to use it. It wasn't an accident or by mistake that we decided to use githash - we decided that would be the better/easier thing to do.

Even in terms of Sematic versioning - you increment MINOR version when you add functionality in a backward compatible manner. Since dropping githash would break things - that's the definition of not backwards compatible.

No so sure on the above. If we properly tag all our releases (of course including when moving minors), it should still be fairly straight for people to check git shas on both iiod and libiio. We could even still continue to save that info in some common header if necessary (or with some command argument).

As for breaking things, well libiio1 is moving it's major so in theory it's expected to break thinks (and at this point it does break if you try to rebuild it). Yes, we do have a compat layer (that's only for runtime) and if there's something we can do to not break things, the better. But I would not block a change like this because of that.

I mean, for users to make real use of libiio1, they will anyways have to rebuild and re-adapt theirs apps for the new API.

FWIW, I don't really agree with this idea of the major number thingy to break compatibility. If you want to complete refactor things just call it another name. So I would have moved libiio to libiio2 just to be explicit about it 😅

@rgetz also for my understanding... How is this breaking current users?

[rgetz]

completely adding minor (and leaving githash as is) so it's:

Releases

• in below, githash is there, populated properly, but not part of the package/file name.
• 1.0.0-rc1 (release candidate one)
• 1.0.0-rc2 (release candidate two)
• 1.0.0 (official release)

Building from source (main or other)

• 1.0.0-githash (daily builds, development builds, etc)

would make more sense to me.

Today we have:

_api __pure unsigned int iio_context_get_version_major(const struct iio_context *ctx);
__api __pure unsigned int iio_context_get_version_minor(const struct iio_context *ctx);
__api __pure const char * iio_context_get_version_tag(const struct iio_context *ctx);

leave those alone, and add

__api __pure unsigned int iio_context_get_version_patch(const struct iio_context *ctx);

would make alot more sense. the compat layer would ignore that, and still report 1.0-gittag for things.

[nunojsa]

That looks sane to me and it is what I would expect to see from a linux package... Having the sha in a dev/daily build is fairly common.

[rgetz]

This should be using ${PROJECT_VERSION_PATCH} per normal/standard cmake semantics.

[rgetz]

@rgetz also for my understanding... How is this breaking current users?

I'm pretty sure - there is an old version of libiio that assumes githash is always a null terminated 8 char string, and uses strcpy, or memcpy to move it around. putting "0" (null) there will cause it to look like a null terminated string, and will not print "0". or could cause undefined results - it wasn't until 2020 that we ran everything through enough analysis tools - and 2022 until I ran it through polyspace checker - which found issues like this...