4.15.2 stable release
alejandro-colomar opened this issue · 14 comments
There have been already a few fixes that I'll would like to backport to the 4.15.x stable branch.
Also, this point release will officially deprecate our groups(1) and id(1) programs (in favor of the ones provided by GNU coreutils and BusyBox), with an announcement in the release notes. The 4.16.0 release will not contain those programs (unless there's opposition to that).
Cc: @ikerexxe, @hallyn, @jubalh, @thesamesam
Changes proposed for 4.15.2:
You may notice that the list above includes most of the changes to the master branch, with only a few commits not being included. Thus, I deem it safer to fast-forward the 4.15.x branch to a commit in master that contains all of those, and do the release from there. It will be safer than cherry-picking a list of dozens of commits (with the chance of making mistakes that it would bring). Doing this will have some superfluous changes in a stable branch, but meh.
So, I would propose fast-forwarding to 9dddcd2 ("STABLE.md: 4.15.x is now stable"), and branching from there. But since that's just 6 commits below the tip of the branch, we may as well go to the tip, which would include changes such as adding the tests/ subdirectory to the dist tarball, so that it will help with the Debian packaging. So I actually propose releasing 4.15.2 from the master branch.
We might as well call it 4.16.0 and drop support for 4.15.x (and so the removal of id(1) and groups(1) would be for 4.17.0).
Proposed release date:
2024-06-09
Hmm?
Also, this point release will officially deprecate our groups(1) and id(1) programs (in favor of the ones provided by GNU coreutils and BusyBox), with an announcement in the release notes. The 4.16.0 release will not contain those programs (unless there's opposition to that).
I think we should deprecate those binaries in 4.16.0 and remove them in 4.17.0. This should give downstream maintainers ample time to get the news and act accordingly.
We might as well call it 4.16.0 and drop support for 4.15.x (and so the removal of id(1) and groups(1) would be for 4.17.0).
Sounds good to me.
Also, this point release will officially deprecate our groups(1) and id(1) programs (in favor of the ones provided by GNU coreutils and BusyBox), with an announcement in the release notes. The 4.16.0 release will not contain those programs (unless there's opposition to that).
I think we should deprecate those binaries in 4.16.0 and remove them in 4.17.0. This should give downstream maintainers ample time to get the news and act accordingly.
We might as well call it 4.16.0 and drop support for 4.15.x (and so the removal of id(1) and groups(1) would be for 4.17.0).
Sounds good to me.
Good. Then @hallyn should do the release, when he considers it appropriate.
4.15.x is EOL, and there will be no 4.15.2. :)
I think we should deprecate those binaries in 4.16.0 and remove them in 4.17.0. This should give downstream maintainers ample time to get the news and act accordingly.
I agree to this.
We might as well call it 4.16.0 and drop support for 4.15.x (and so the removal of id(1) and groups(1) would be for 4.17.0).
This might be too fast for the deprecation note to trickle downstream. But not sure :)
Edit: Also a 4.1.5x release might let Enterprise distributions which use the last 4.15.y release more easily update.
I think we should deprecate those binaries in 4.16.0 and remove them in 4.17.0. This should give downstream maintainers ample time to get the news and act accordingly.
I agree to this.
Ok.
We might as well call it 4.16.0 and drop support for 4.15.x (and so the removal of id(1) and groups(1) would be for 4.17.0).
This might be too fast for the deprecation note to trickle downstream. But not sure :) Edit: Also a 4.1.5x release might let Enterprise distributions which use the last 4.15.y release more easily update.
I was preparing it, but the thing is, I would have to cherry-pick around half of the commits in the range 4.15.1..shadow/master, plus maybe a few others to resolve conflicts. At least 25 commits would be cherry-picked, from 53; possibly more. So, I think it's safer to fast-forward to master, instead of branching + cherry-picking, even if that includes 28 commits that are unnecessary. Or do you think it would be worth branching?
If we fast-forward, I think it's more appropriate to bump the minor version, since it's not just bugfixes, but yeah, we could keep the name as 4.15.2 just to keep enterprise distros happy.
So, we have 3 alternatives:
- Fast-forward 4.15.x to master, and release 4.15.2 from it.
- EOL 4.15.x. Release 4.16.0 from master.
- Branch, and cherry-pick half of the commits in master, for a 4.15.2.
I don't like the third. I slightly prefer the second, but only slightly, so if distros prefer the first, I'm fine with it.
If we fast-forward, I think it's more appropriate to bump the minor version, since it's not just bugfixes
Ah I see. The following sentence in the first comment made me think that the goal was to have a bugfix release only:
There have been already a few fixes that I'll would like to backport to the 4.15.x stable branch.
If we fast-forward, I think it's more appropriate to bump the minor version, since it's not just bugfixes
Ah I see. The following sentence in the first comment made me think that the goal was to have a bugfix release only:
There have been already a few fixes that I'll would like to backport to the 4.15.x stable branch.
That was the intention, when I wrote it.
Then I started searching for the commits that would have to be cherry-picked, and realized it wasn't viable, and wrote the rest of the post. :)
I can aim to cut a 4.16.0-rc1 on Thursday, June 13, and if that all checks out, release 4.16.0 on Saturday morning, June 15. Does that sound good?