[Openvas-devel] Planning OpenVAS 4 Beta

Stephan Kleine bitdealer at gmail.com
Mon Nov 8 15:45:28 CET 2010


On Monday November 8 2010 12:06:21 Jan-Oliver Wagner wrote:
> On Freitag, 5. November 2010, Nigel Taylor wrote:
> > I have no problem with using 3.98.1, 3.98.2, 3.99.1, 3.99.2.
> > 
> > If source is released as 4.0.0~beta1 then I will rename the package to
> > 4.0-beta1. If source is released as 3.98.1,then I will use 3.98.1, I
> > don't want to get source 4.0.0~beta1 and produce a package 3.98.1.
> 
> I don't really like the 3.98.x approach because 3.x releases should
> be compatible in some way. But if 3.98.x introduces features
> of 4.0 then 3.98.x is incompatible with other 3.x releases
> and thus can cause confusion.
> 
> IMHO the the following would do the job and yet remain simple
> enough to understand.
> Should help both, OpenVAS developers and packagers?
> 
> 
> How to apply version number for OpenVAS
> ---------------------------------------
> 
>  * Any stable release should be given a version number N.N.N.
>    Thus source code tarballs are named "module-name-N.N.N.tar.gz"
> 
>  * Any Beta and RC release refers to a next major release, never
>    a minor release. Thus versions like "N.N-beta1" or "N.N-rc1"
>    are applicable, but not "N.N.N-rc1".
>    This ensures, that for example 2.0.0 is greater than 2.0-beta1
>    when applying simple version comparison.

Which doesn't work cause rpm doesn't allow "-" in the version string so one 
had to use 2.0.beta1 which is "bigger" than 2.0.0.

I'm no friend of the 3.98.x style either but that way it simply works. Also it 
is used by several major projects as well (and the .98 somehow shows that it 
is more 4 than 3) and I would really guess if there were a better alternative 
those would have been found and used quite some time ago.


More information about the Openvas-devel mailing list