upgrade from 9.0.3 to 1.0.0 version

[fcolista]

hi team.
Just want to mention that set a new version from 9.0.3 to 1.0.0 makes the upgrade path difficult.
Package managers saw it as a downgrade because for the number.
There's a reason why it is not set as 10.0.0 ?
Thanks.

.: Francesco

[bjoernricks]

It's NOT a 10.0.0 version of openvas-libraries. It's a cleanup and rewrite called gvm-libs. Therefore the version number is 1.0. ABI and API is different.

[fcolista]

here: https://github.com/greenbone/gvm-libs/releases/tag/v9.0.3

You have named it gvm-libs with 9.0.3 version.
This means that some package mangers have set gvm-libs to that very version since you have annonced that openvas-libraris would have been renamed to gvm-libs.

.: Francesco

[bjoernricks]

This git repo contains to different libraries:

1. openvas-libraries (latest release 9.0.3)
2. gvm-libs (first and latest release 1.0.0)

Can't imagine we ever advised packagers to include openvas-libraries as gvm-libs. Even the branches make that obvious https://github.com/greenbone/gvm-libs/branches/all

As I said gvm-libs is a rewrite and cleanup of the openvas-libraries.

[bjoernricks]

I even believe both libraries are co-installable. If not I would consider this as a bug.

[fcolista]

The versioning you are using is not consistent between the package and the libs as you used to do before.
Here you have mention: https://community.greenbone.net/t/about-the-source-edition-gse-category/176
"GVM-9 (stable, previously named OpenVAS-9)".
And here:
https://community.greenbone.net/t/gvm-9-stable-initial-release-2017-03-07/211
"GVM/OpenVAS Libraries 9.0.3"
That openvas-libraries 9.0.3 is also called gvm-libs.
And the source url of the github repository shows that.
So, what does the people should understand?
You are breaking the consistency between libs and the package, and this causes difficulties to package managers because is seen as a downgrade.
You should have set gvm-libs to 10.0.0, keeping the consistency.

.:Francesco

[bjoernricks]

We are not packaging any of our software components for a distribution other then the Greenbone OS. To be clear we never advised a package rename of openvas-libraries to gvm-libs.

Of course openvas-libraries is the ancestor of gvm-libs and therefore they have been put into the same git repository. But both are different libraries from a packagers view.

I am sorry if this wasn't clear enough for outside packagers. Please next time create a topic at https://community.greenbone.net/ if in doubt.

[fcolista]

Sorry, but this sentence does not make much sense:
"We are not packaging any of our software components for a distribution other then the Greenbone OS. "
Since you are distributing sources, you cannot say "we don't care about the others".
You know that basically ALL distributions have in their repository openvas/greenbone.
So, please, be clear and consistent in order to not create issue to the rest of the world.
And if you are planning to put version as you like, please announce it before, to keep the life easier to others.
Thanks.
.: Francesco

[bjoernricks]

"We are not packaging any of our software components for a distribution other then the Greenbone OS. "
Since you are distributing sources, you cannot say "we don't care about the others".

I haven't said that and I am never going to say that. Please be polite. I am not offending you. I am only clarifying how gvm-libs is supposed to be packaged from our side. I am really sorry if this wasn't obvious to you.

I can understand why this confusion happened from the GVM 9 announcement but looking at the sources should give you at least some doubts about gvm-libs is only a rename of openvas-libraries.
Names, headers, version, license, API, ABI and SO versions are different in gvm-libs. The releases for the 9.0 branch is still referencing openvas-libraries as the name. The first release of gvm-libs 1.0 was only made some days ago.

So please please get in touch with us and ask me or my co-workers before doing such changes next time.

[fcolista]

@bjoernricks I won't be rude, sorry if I gave that impression.
I think that the way you managed this rename/reversion is wrong.
You should have used a new git repo for this new project. This would not have lead to a confusion.
Take this into consideration, if you (next time) are going to do the same.
Thanks for your attention and sorry for the noise.
Feel free to close this thread.

.: Francesco

[bjoernricks]

You should have used a new git repo for this new project. This would not have lead to a confusion.
Take this into consideration, if you (next time) are going to do the same.

Yes next time I would propose to split the git repository to avoid confusion.