search

shadow-maint / shadow

Upstream shadow tree
Other
287 stars 227 forks source link

4.15.2 stable release #1010

Closed alejandro-colomar closed 3 weeks ago

alejandro-colomar commented 1 month ago

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).

Link: #1008 Link: #1005

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 9dddcd29f131 ("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?

ikerexxe commented 1 month ago

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.

alejandro-colomar commented 1 month ago

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. :)

jubalh commented 1 month ago

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.

alejandro-colomar commented 1 month ago

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:

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.

jubalh commented 1 month ago

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.

alejandro-colomar commented 1 month ago

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. :)

hallyn commented 1 month ago

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?

alejandro-colomar commented 1 month ago

On Tue, Jun 11, 2024 at 02:18:51PM GMT, Serge Hallyn wrote:

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?

Yep; that sounds good.

Please add to the release notes of 4.16.0 (and maybe also in the -rc1) that our id(1) and groups(1) are deprecated in favor of the GNU coreutils and binutils versions, and that they'll be removed in 4.17.0. https://github.com/shadow-maint/shadow/pull/1008#issuecomment-2137389500

Also, please anounce that 4.15.x is EOL, and that distros using it should upgrade to the 4.16.x series. There are no breaking changes, so it should be fine.

Cheers, Alex

-- Reply to this email directly or view it on GitHub: https://github.com/shadow-maint/shadow/issues/1010#issuecomment-2161613335 You are receiving this because you authored the thread.

Message ID: @.***>

-- https://www.alejandro-colomar.es/

hallyn commented 4 weeks ago

@alejandro-colomar by "release notes" do you mean on the github release page? Or are you referring to shadow.git/ChangeLog?

alejandro-colomar commented 4 weeks ago

@alejandro-colomar by "release notes" do you mean on the github release page? Or are you referring to shadow.git/ChangeLog?

@hallyn Was referring to github release page. Maybe also the git tag.

I have never looked at the ChangeLog, TBH. :)

alejandro-colomar commented 4 weeks ago

On Thu, Jun 13, 2024 at 04:09:14PM GMT, Serge Hallyn wrote:

@alejandro-colomar by "release notes" do you mean on the github release page? Or are you referring to shadow.git/ChangeLog?

BTW, I'm now not sure if we can claim 4.16.0 to have no breaking changes compared to 4.15.1. Here's Iker's comment about that: https://github.com/shadow-maint/shadow/pull/1019#issuecomment-2165791012

-- Reply to this email directly or view it on GitHub: https://github.com/shadow-maint/shadow/issues/1010#issuecomment-2166932300 You are receiving this because you were mentioned.

Message ID: @.***>

-- https://www.alejandro-colomar.es/

hallyn commented 3 weeks ago

@alejandro-colomar have you tested out the 4.16.0-rc1 ?

alejandro-colomar commented 3 weeks ago

@hallyn No, but I don't usually do much work with these tools (I don't maintain any multi-user systems), so I'm not a good test bed. I tested groupadd(8) and groupmod(8) for the bug that was fixed recently, but not much more than that.

alejandro-colomar commented 3 weeks ago

4.15.2 and 4.14.8 have been released.