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 like Version: 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, currently 5. 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:
dpkg --compare-versions '5+3.0.1' '>>' '5+3.0.0'
dpkg --compare-versions '5+4.0.0' '>>' '5+3.0.1'
dpkg --compare-versions '6+1.0' '>>' '5+4.0.0'
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?
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?