Eliminate git sha from version in case of release #1188

AAndrisa · 2024-08-01T13:26:03Z

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)

For the PATCH value of the VERSION variable the git sha of the last commit was used, but in case of a release we want to change that value to 0, so it can be added in a package repository. If we set an environment variable IS_RELEASE then the PATCH variable will remain 0, otherwise will still be initialized with git sha. Signed-off-by: Andreea Andrisan <[email protected]>

After switching to patch variable artifact check also needs to be updated. Signed-off-by: Andreea Andrisan <[email protected]>

In order to extract the git sha of the last commit from libiio the directory where a volume of the project was created needs to be set as safe, otherwise an error message will appear. Signed-off-by: Andreea Andrisan <[email protected]>

In order to maintain the same length of the git sha during package creation all the jobs must have the same parameters at repository checkout. Signed-off-by: Andreea Andrisan <[email protected]>

AAndrisa · 2024-08-01T13:29:13Z

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

rgetz · 2024-08-03T22:50:49Z

iiod/iiod.c

@@ -296,7 +296,7 @@ static int start_iiod(const char *uri, const char *ffs_mountpoint,

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


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.

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.

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.

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

rgetz · 2024-08-03T22:54:42Z

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 · 2024-08-03T23:04:52Z

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 · 2024-08-05T07:59:40Z

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 · 2024-08-05T08:09:16Z

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 · 2024-08-05T08:11:13Z

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 · 2024-08-05T17:28:01Z

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 · 2024-08-05T17:32:03Z

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.

In case the build was triggered for a release purpose we don't want to use the git sha in the version of libiio. The new variable will be used in order to identify that is a build dedicated to a release. Signed-off-by: Andreea Andrisan <[email protected]>

AAndrisa · 2024-08-06T13:11:30Z

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 · 2024-08-07T08:01:30Z

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 · 2024-08-07T13:06:42Z

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 · 2024-08-07T15:13:27Z

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 · 2024-08-07T22:11:29Z

CMakeLists.txt

@@ -15,6 +15,7 @@ endif()

 set(LIBIIO_VERSION_MAJOR ${PROJECT_VERSION_MAJOR})
 set(LIBIIO_VERSION_MINOR ${PROJECT_VERSION_MINOR})
+set(LIBIIO_VERSION_PATCH 0)


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

rgetz · 2024-08-07T22:22:48Z

@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...

AAndrisa added 4 commits July 29, 2024 16:09

artifact_manifest.txt.cmakein: replace git sha variable with patch

340f71c

After switching to patch variable artifact check also needs to be updated. Signed-off-by: Andreea Andrisan <[email protected]>

azure-pipelines.yml: add checkout specifications

c6d322a

In order to maintain the same length of the git sha during package creation all the jobs must have the same parameters at repository checkout. Signed-off-by: Andreea Andrisan <[email protected]>

AAndrisa requested review from cristina-suteu, dNechita, mhennerich and SRaus as code owners August 1, 2024 13:26

AAndrisa requested a review from nunojsa August 1, 2024 13:27

rgetz reviewed Aug 3, 2024

View reviewed changes

AAndrisa force-pushed the release_patch branch from 76f2947 to 7b407c4 Compare August 6, 2024 11:30

rgetz reviewed Aug 7, 2024

View reviewed changes

AAndrisa marked this pull request as draft September 2, 2024 12:45

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Eliminate git sha from version in case of release #1188

Eliminate git sha from version in case of release #1188

AAndrisa commented Aug 1, 2024

AAndrisa commented Aug 1, 2024

rgetz Aug 3, 2024

SRaus Aug 5, 2024

AAndrisa Aug 6, 2024

rgetz Aug 7, 2024

rgetz commented Aug 3, 2024

rgetz commented Aug 3, 2024

SRaus commented Aug 5, 2024

SRaus commented Aug 5, 2024

SRaus commented Aug 5, 2024

rgetz commented Aug 5, 2024

rgetz commented Aug 5, 2024

AAndrisa commented Aug 6, 2024

nunojsa commented Aug 7, 2024

rgetz commented Aug 7, 2024

nunojsa commented Aug 7, 2024 •

edited

Loading

rgetz Aug 7, 2024

rgetz commented Aug 7, 2024

Eliminate git sha from version in case of release #1188

Are you sure you want to change the base?

Eliminate git sha from version in case of release #1188

Conversation

AAndrisa commented Aug 1, 2024

PR Description

PR Type

PR Checklist

AAndrisa commented Aug 1, 2024

rgetz Aug 3, 2024

Choose a reason for hiding this comment

SRaus Aug 5, 2024

Choose a reason for hiding this comment

AAndrisa Aug 6, 2024

Choose a reason for hiding this comment

rgetz Aug 7, 2024

Choose a reason for hiding this comment

rgetz commented Aug 3, 2024

rgetz commented Aug 3, 2024

SRaus commented Aug 5, 2024

SRaus commented Aug 5, 2024

SRaus commented Aug 5, 2024

rgetz commented Aug 5, 2024

rgetz commented Aug 5, 2024

AAndrisa commented Aug 6, 2024

nunojsa commented Aug 7, 2024

rgetz commented Aug 7, 2024

Releases

Building from source (main or other)

nunojsa commented Aug 7, 2024 • edited Loading

rgetz Aug 7, 2024

Choose a reason for hiding this comment

rgetz commented Aug 7, 2024

nunojsa commented Aug 7, 2024 •

edited

Loading