Skip to content
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.

Sign up for GitHub

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

Jump to bottom

New official release before Debian 11 freeze (needed for projects) #561

Closed
Neustradamus opened this issue Jan 3, 2021 · 42 comments · Fixed by #565
Closed

New official release before Debian 11 freeze (needed for projects) #561

Neustradamus opened this issue Jan 3, 2021 · 42 comments · Fixed by #565

Comments

@Neustradamus
Copy link

Hello the Team, @tuexen,

I wish you a Happy New Year!

It is possible to create a real new build instead of a git version?
The goal is to have the version before the Debian 11 freeze (2021-01-12).

It is used by several projects like Psi and Psi+.

The last official version is very old, soon 5 years:

Thanks in advance.
@tehnick
Copy link

tehnick commented Jan 3, 2021 •
edited
Loading

The last official version is very old, soon 5 years

That is why GNU/Linux distributions are forced to use git snapshotes:
https://tracker.debian.org/pkg/libusrsctp
https://launchpad.net/ubuntu/+source/libusrsctp
https://pkgs.alpinelinux.org/packages?name=libusrsctp-dev

And even in *BSD systems:
https://www.freshports.org/net/libusrsctp
https://github.com/DragonFlyBSD/DPorts/tree/master/net/libusrsctp

@tuexen
Copy link
Member

tuexen commented Jan 3, 2021

... and what would you expect from a release compared to a snapsot?

@jonassmedegaard
Copy link

jonassmedegaard commented Jan 3, 2021 via email

@tehnick
Copy link

tehnick commented Jan 3, 2021

... and what would you expect from a release compared to a snapsot?

Just git tag. Nothing more. Github will prepare tarball for git tag automatically. And this new version will be widely used in different distros and build environments (like Homebrew).

But if you can write a short change log (for example with API changes) it would much better of course.

@Neustradamus
Copy link
Author

Gentoo too:

Fedora 31/32/33/34 have another versions:

Time to release the 1.0.0+ after several years.

The most important is Debian 11 freeze in few days, the next will be in 2023.

@Neustradamus
Copy link
Author

Notes:

@Neustradamus
Copy link
Author

Neustradamus commented Jan 6, 2021 •
edited
Loading

Hello the Team, @tuexen,

Have you looked?
A new build is needed, it can be released today?

@jonassmedegaard: Can you create a build with the last current git?
Timing is very short.

Several projects need up-to-date...

Thanks in advance.

cc @xvitaly

@xvitaly
Copy link
Contributor

xvitaly commented Jan 6, 2021

cc @xvitaly

On Fedora, we already have a packaged version of usrsctp, but built from Git snapshot.

@Neustradamus
Copy link
Author

@xvitaly: Yes, read my comment:

Fedora 31/32/33/34 have another versions:

Time to release the 1.0.0+ after several years.

I think that @tuexen does not want to create a new build and I have specified that you have done 1.0.0.
It is a problem for all projects because:

Some projects can not be added because the lib is outdated since 5 years soon.

Normally, there are not git-version products in some OS...

I hope a new version today, the most important is Debian 11 (The next will be in 2023), and there will be Fedora 34 soon too.

@xvitaly
Copy link
Contributor

xvitaly commented Jan 6, 2021

I hope a new version today, the most important is Debian 11 (The next will be in 2023), and there will be Fedora 34 soon too.

If a new version will be released soon, I will push it to all supported Fedora releases: from 32 to 34.

@tuexen
Copy link
Member

tuexen commented Jan 6, 2021

I have at least to fix one known issue before making a release. And I got another issue reported, I have to look into. So there will not be a release today.

@Neustradamus
Copy link
Author

@tuexen: Thanks for your reply!
I cross my fingers...

@Neustradamus
Copy link
Author

@tuexen: After 4 days, it is good?

It blocks several projects on Debian here...

Can you do it today?

I propose you a 1.0.0 or a 1.0.1 version.

Thanks in advance.

@tuexen
Copy link
Member

tuexen commented Jan 10, 2021

I can do it today, but it will be 0.9.4.
1.0.0 will happen once it is feature complete (meaning complete RFC 8260 support) and there are no known critical bugs for a while.

@tuexen
Copy link
Member

tuexen commented Jan 10, 2021

@tuexen: After 4 days, it is good?

You assume that i had time to look into the bug I was referring to, but I hadn't.

It blocks several projects on Debian here...

Not sure why you can't use some snapshots based on a particular git version.

Can you do it today?

Done.

I propose you a 1.0.0 or a 1.0.1 version.

0.9.4.0 is the next after 0.9.3.0.

Thanks in advance.

@xvitaly
Copy link
Contributor

xvitaly commented Jan 10, 2021 •
edited
Loading

0.9.4.0 is the next after 0.9.3.0.

But this is not a 0.9.x. It contains lots of changes and breaks API and ABI between 0.9.3.0 and 0.9.4.0. This is even worse than it was.

@xvitaly
Copy link
Contributor

xvitaly commented Jan 10, 2021 •
edited
Loading

Minor releases must not break API and ABI. Such changes should be a major release with SOVERSION bump. If you don't want to publish 1.0.0, you can use 0.10.0.0.

@tehnick
Copy link

tehnick commented Jan 10, 2021

It blocks several projects on Debian here...
Not sure why you can't use some snapshots based on a particular git version.

This was misinformation from @Neustradamus . Debian is fine with git snapshots. Real inconvenience was in different versions of library with incompatible API used across different GNU/Linux distros and even between different versions of one distro...

Thanks for a new release!

@jonassmedegaard
Copy link

jonassmedegaard commented Jan 10, 2021 via email

@jonassmedegaard
Copy link

jonassmedegaard commented Jan 10, 2021 via email

@tuexen
Copy link
Member

tuexen commented Jan 10, 2021

Minor releases must not break API and ABI. Such changes should be a major release with SOVERSION bump. If you don't want to publish 1.0.0, you can use 0.10.0.0.

I'm trying to keep the API stable. So where did it break? Please also note that the version number is below 1.0.0, so I consider it acceptable to break the API, if there are good reasons for it.

Not sure about SOVERSION, that is a cmake thing.
@weinrank What is SOVERSION? Is this something like the version information in configure.ac? Then it should be in sync and it should be 0.9.4 right now.

@tuexen
Copy link
Member

tuexen commented Jan 10, 2021

0.9.4.0 is the next after 0.9.3.0.

But this is not a 0.9.x. It contains lots of changes and breaks API and ABI between 0.9.3.0 and 0.9.4.0. This is even worse than it was.

Where is it API broken? If you don't like this release, can't you just ignore it?

@taylor-b
Copy link
Contributor

I know of one place where the API changed recently; the send_cb passed into usrsctp_socket added an additional void* ulp_info argument.

@Neustradamus
Copy link
Author

@taylor-b: Thanks for comment, it is linked to:

@tehnick
Copy link

tehnick commented Jan 11, 2021

@tuexen Yes, SOVERSION itself is a cmake stuff. But it is needed just for simplifying maintaining of library for completely different systems. In case of GNU/Linux systems and other systems with binaries in ELF format, this SOVERSION variable in cmake is used for setting proper SONAME in a shared library.

@xvitaly
Copy link
Contributor

xvitaly commented Jan 11, 2021

By the way, cmake and meson are still exporting version 1.0.0.

I think I will continue using this version (1.0.0) in Fedora packages.

@jonassmedegaard
Copy link

jonassmedegaard commented Jan 11, 2021 via email

@xvitaly
Copy link
Contributor

xvitaly commented Jan 11, 2021 •
edited
Loading

It is (most likely) not a project version, but a SONAME version:

Currently exported by Cmake and Meson:

  • project version: 1.0.0
  • SONAME version: 1

@Neustradamus
Copy link
Author

@tuexen: You have all points to create an official 1.0.0 version.
Can you do it?

@jonassmedegaard: I hope that it is good for timing...

@Neustradamus
Copy link
Author

Note:
The bad number version in the file: 0.9.4.0 -> 1.0.0.0

Good files have "1.0.0"/"1.0.0.0"/"1:0:0":

Maybe good to harmonize all "1.0.0" or "1.0.0.0" same values.

Thanks in advance.

@jonassmedegaard
Copy link

jonassmedegaard commented Jan 11, 2021 via email

@xvitaly
Copy link
Contributor

xvitaly commented Jan 11, 2021

Seems to me that Michael already informed us the criteria for a major release - so if som build hints state that already the most logical would be to treat that as flaws to correct, not reasons for fast-pacing a major release.

Current version 0.9.4.0 has soversion 1:1.0.0 even in automake.

@Neustradamus
Copy link
Author

The problem is that it is specified in files: "1.0.0"/"1.0.0.0"/"1:0:0", it is not "0.9.4.0" except one place, there is a bad value.

@lgrahl
Copy link
Contributor

lgrahl commented Jan 11, 2021

I think I took 1.0.0 from the CMake files when I was writing the Meson build files. It's unfortunate that there was a 1.0.0 now. But would it really hurt to give up the tight binding of feature completeness to 1.0 now that the damage is done? Or is that version scheme something that the FreeBSD kernel mandates?

This project would likely benefit from collectively bumping all version numbers and perhaps add a very small releasing document describing what needs to be done on a release (e.g. "bump all the version numbers in files x, y and z, create a git tag, push, done").

@jonassmedegaard
Copy link

jonassmedegaard commented Jan 11, 2021 via email

@tehnick
Copy link

tehnick commented Jan 11, 2021

not reasons for fast-pacing a major release.

+1

Current version 0.9.4.0 has soversion 1:1.0.0 even in automake.

And this is not a problem: SONAME is not related to program version at all. It has only one real requirement: it should be incremented between releases if there are changes in ABI. For example, library libfoo with version 0.16.1 may be with SONAME libfoo_49 and this is completely normal.

@Neustradamus Please stop write these similar messages. They are useless and annoying.

@tehnick
Copy link

tehnick commented Jan 11, 2021 •
edited
Loading

Where is it API broken?

As a Psi+ packages maintainer I have faced with differences in libusrsctp versions
0.9.3.0+20190901, 0.9.3.0+20200422 and 0.9.3.0+20201102 in different versions of Ubuntu:
https://launchpad.net/ubuntu/+source/libusrsctp

Unfortunately, I have not found full build logs, but IIRC the problem was in usrsctp_getsockopt() function.

In our official PPA for Ubuntu this problem was solved by uploading latest version of libusrsctp package to our PPA:
https://launchpad.net/~psi-plus/+archive/ubuntu/ppa/+packages
and by setting of specific minimal version of library in binary packages:
https://salsa.debian.org/xmpp-team/psi-plus/-/blob/511e295d/debian/control#L40

In Debian this will not be a problem because Debian Bullseye already has version 0.9.3.0+20201102 and I hope that it will appear in official backports for Debian Buster soon: https://tracker.debian.org/pkg/libusrsctp

After release of version 0.9.4.0 I expect that all popular distros will update their libusrsctp packages to this new version in a foreseeable future and this mess with git snapshots with different API will go away.

As for first stage of Debian Bullseye freeze since 12 Jan 2021, I do not see the problem of updating package with library to version 0.9.4.0, because there are very few changes in it since version 0.9.3.0+20201102 (which is in Debian testing now), so slot for library transition is not required.

From my point of view this issue may be closed.

@tuexen Thanks for such fast reaction!

@Neustradamus Neustradamus mentioned this issue Jan 12, 2021
Closed
@Neustradamus
Copy link
Author

Interesting :)

@tuexen
Copy link
Member

tuexen commented Jan 12, 2021

I think I took 1.0.0 from the CMake files when I was writing the Meson build files. It's unfortunate that there was a 1.0.0 now. But would it really hurt to give up the tight binding of feature completeness to 1.0 now that the damage is done? Or is that version scheme something that the FreeBSD kernel mandates?

This project would likely benefit from collectively bumping all version numbers and perhaps add a very small releasing document describing what needs to be done on a release (e.g. "bump all the version numbers in files x, y and z, create a git tag, push, done").

Can you prepare a pull request for it? I would like to keep the project version consistent between the autotools builds, the cmake builds and the mesa builds. Let us sync them to the autotools version.

It would also be good to understand how the build systems set the soversion and what the requirements are there. Something like bump it this when changing the API.

That way we can maybe meet the expectations some people have.

@xvitaly xvitaly mentioned this issue Jan 13, 2021
Merged
@xvitaly
Copy link
Contributor

xvitaly commented Jan 13, 2021

Can you prepare a pull request for it?

#565 should fix all these issues.

@Neustradamus
Copy link
Author

For your information, Debian 12 arrives... After 2 years.

@Neustradamus
Copy link
Author

@tuexen: It is possible to have a new release after 2 years of development?

@reckenrode reckenrode mentioned this issue Oct 23, 2023
Merged
13 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Unified version and soversion between all supported build systems
7 participants
@tuexen @Neustradamus @tehnick @jonassmedegaard @xvitaly @lgrahl @taylor-b