-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Debian package contains libbeat snapshot version only #10
Comments
Hi @jautz, thank you for your feedback. This is a known issue in the beat infrastructure code and is planned to be fixed in the next major version and then also fixed in the execbeat. |
Thank you, @christiangalsterer for your quick reply. It would be great if you could give me additional hints to these questions:
|
Seems that it is also available in 5.2.1. Will look into it next days. |
Just tried it and it works (partially). One can set now indeed the version, but it is always suffixed with SNAPSHOT. Need to look into it. |
Seems that I also found the switch for this. Will do some further tests tomorrow before releasing a new version. |
Release 3.1.1 is now available. |
Great, thank you for your effort to get this fixed within one day. |
First of all: thank you for providing your software as Debian packages. There is one thing that in probably a bug, however:
From a dpkg/apt perspective the relevant version is not the one encoded in the file name but the one in the
debian/control
Version field. The execbeat packages contain a version sting likeVersion: 5.2.1-SNAPSHOT
. This is not only a cosmetic issue because with the latest releases it became obvious that this version field does not change unless execbeat has its underlying libbeat version updated.To clarify: both 3.0.0 and 3.0.1 are version 5.2.1-SNAPSHOT from the Debian perspective.
I would like to propose a different versioning scheme in the control file. I know that versioning schemes are a question of taste, so please take it as it is meant: as a suggestion.
One could simply put
3.0.1
there. But maybe it is a good idea to keep aligned with the major version of the elastic stack, currently5
. According to the debian policy the Version field's upstream version may contain additional characters. How about this:5+3.0.1
? Personally, I would also add the debian revision-1
suffix that makes it possible to release the same upstream version again with-2
if something is wrong with the packaging itself.The following expressions yield true:
The last example illustrates that one could even completely change the execbeat versioning scheme when the elastic stack major version changes.
To cut to the chase: there are many possibilities. But the main questions are: can you influence the debian/control file Version field in the context of your packaging process and if so, are you willing to change it?
The text was updated successfully, but these errors were encountered: