-
Notifications
You must be signed in to change notification settings - Fork 281
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.
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
New official release before Debian 11 freeze (needed for projects) #561
Comments
That is why GNU/Linux distributions are forced to use git snapshotes: And even in *BSD systems: |
... and what would you expect from a release compared to a snapsot? |
Quoting Michael Tüxen (2021-01-03 21:53:38)
... and what would you expect from a release compared to a snapsot?
A version number corresponding with a git tag, which consuming projects and downstream distributions can reference.
If all git commits are considered equally stable changes, then it is helpful if that is documented - and then (but only then) does it make less sense to issue formal releases (because then each and every commits implies a "release").
|
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. |
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. |
Hello the Team, @tuexen, Have you looked? @jonassmedegaard: Can you create a build with the last current git? Several projects need up-to-date...
Thanks in advance. cc @xvitaly |
On Fedora, we already have a packaged version of usrsctp, but built from Git snapshot. |
@xvitaly: Yes, read my comment:
I think that @tuexen does not want to create a new build and I have specified that you have done 1.0.0.
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. |
If a new version will be released soon, I will push it to all supported Fedora releases: from 32 to 34. |
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. |
@tuexen: Thanks for your reply! |
@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. |
I can do it today, but it will be 0.9.4. |
You assume that i had time to look into the bug I was referring to, but I hadn't.
Not sure why you can't use some snapshots based on a particular git version.
Done.
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. |
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. |
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! |
Quoting Michael Tüxen (2021-01-10 10:53:55)
> @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.
Debian package maintainer for usrsctp here.
Yes, Debian uses git snapshots, and I am unaware of any blockers.
There certainly are none propery reported at https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=libusrsctp
That said, I appreciate upstream releases being made. Thanks!
- Jonas
|
Quoting Vitaly Zaitsev (2021-01-10 10:56:29)
Minor releases must not break API and ABI. Such changes should be a major release with SOVERSION bump.
I suspect you are mistaking "versions" with "SemVer 2.0.0 versioning scheme compliant versions" or something similar (SemVer sure wasn't the first invention of applying semantics to version components)
|
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. |
Where is it API broken? If you don't like this release, can't you just ignore it? |
I know of one place where the API changed recently; the |
@taylor-b: Thanks for comment, it is linked to: |
@tuexen Yes, |
Quoting Vitaly Zaitsev (2021-01-11 15:37:26)
By the way, [cmake](https://github.com/sctplab/usrsctp/blob/master/usrsctplib/CMakeLists.txt#L37) and [meson](https://github.com/sctplab/usrsctp/blob/master/meson.build#L3) are still exporting version 1.0.0.
I think I will continue using this version (1.0.0) in Fedora packages.
It is (most likely) not a project version, but a SONAME version:
https://en.wikipedia.org/wiki/Soname
|
Currently exported by Cmake and Meson:
|
@tuexen: You have all points to create an official 1.0.0 version. @jonassmedegaard: I hope that it is good for timing... |
Note: 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. |
Quoting Neustradamus (2021-01-11 16:29:35)
@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...
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. |
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. |
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"). |
Quoting Vitaly Zaitsev (2021-01-11 16:59:45)
> 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.
There is nothing wrong with project version and SONAME version being different.
|
+1
And this is not a problem: @Neustradamus Please stop write these similar messages. They are useless and annoying. |
As a Psi+ packages maintainer I have faced with differences in Unfortunately, I have not found full build logs, but IIRC the problem was in In our official PPA for Ubuntu this problem was solved by uploading latest version of In Debian this will not be a problem because Debian Bullseye already has version After release of version 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 From my point of view this issue may be closed. @tuexen Thanks for such fast reaction! |
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. |
#565 should fix all these issues. |
For your information, Debian 12 arrives... After 2 years. |
@tuexen: It is possible to have a new release after 2 years of development? |
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).
cc @jonassmedegaard
It is used by several projects like Psi and Psi+.
The last official version is very old, soon 5 years:
Thanks in advance.
The text was updated successfully, but these errors were encountered: