Repository navigation
Debian package contains libbeat snapshot version only #10
Description
Activity
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:
- Could you please point me to the known issue you mentioned? I did not find it through the search engine (probably failed to use the right keywords).
- Do you already know how the versioning scheme will look like when this is fixed (your version / their version / both)?
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.
Reacted by Joachim Jautz, Thomas Kerpe and MattRiestererRelease 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/controlVersion 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.1there. 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-1suffix that makes it possible to release the same upstream version again with-2if 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?