Skip to content

Write up NEWS rules #19387

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Write up NEWS rules #19387

wants to merge 4 commits into from

Conversation

derickr
Copy link
Member

@derickr derickr commented Aug 6, 2025

This addition documents how to update NEWS in one place, instead of it being on the wiki, here, and scattered throughout documents.

I believe that I have documented the current practise, but comments welcome.

@derickr derickr force-pushed the write-up-news-rules branch 6 times, most recently from 09f111e to ad25e20 Compare August 6, 2025 10:21
@derickr derickr marked this pull request as ready for review August 6, 2025 10:22
@derickr derickr requested review from bukka and iluuu1994 August 6, 2025 10:22
Copy link
Member

@iluuu1994 iluuu1994 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we also clarify UPGRADING, and whether new features must go into both NEWS and UPGRADING? This is still handled inconsistently. I usually only add it to UPGRADING, but some people do both.

When you change the NEWS file for a bug fix, then please keep the bugs sorted in
decreasing order under the fixed version.
When you change the NEWS file for a bug fix, then please keep the bugs sorted
under the fixed version.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, this hints at the fact that the patch notes of multiple versions live in the same NEWS file, but it makes it sound like the list itself must be ordered in some way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it sounds quite confusing...

Fixed bug GH-{number} ({issue-description}). ({contributor})

Bug fix entries SHOULD be clustered together, and ordered according to their
issue number. The `{issue-description}` SHOULD represent what the actual bug
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that I mind, but I've never seen entries being listed by issue number, and I see no value-add for this. Usually people just append to the bottom of the list. Maybe that's what the text I previously commented on referred to.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a rule that has been relaxed in the last decade, but we used to be very deliberate doing it this way.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay. I was unaware of that, seems rather useless. But I can adapt.

@iluuu1994
Copy link
Member

Btw, isn't this something that should live in https://github.com/php/policies/?

@derickr
Copy link
Member Author

derickr commented Aug 8, 2025

To answer all the other single-comment comments:

Could we also clarify UPGRADING, and whether new features must go into both NEWS and UPGRADING? This is still handled inconsistently. I usually only add it to UPGRADING, but some people do both.

This was about NEWS, and new features should be in there. It's a full overview of what is in the release. We can tackle UPGRADING in a future patch.

I can also add a section on UPGRADING. For what I understood that should contain all the information that you need for upgrading between versions. So it should document changes, deprecations (with their alternatives), etc. I don't think it needs to contain new features, but that doesn't seem to be how it is currently used.

IIUC, this hints at the fact that the patch notes of multiple versions live in the same NEWS file, but it makes it sound like the list itself must be ordered in some way.

I don't understand what you're trying to say here.

Btw, isn't this something that should live in https://github.com/php/policies/?

Maybe? It was always here, and I didn't see a reasonable location in policies for this.

@iluuu1994
Copy link
Member

IIUC, this hints at the fact that the patch notes of multiple versions live in the same NEWS file, but it makes it sound like the list itself must be ordered in some way.

I don't understand what you're trying to say here.

Disregard, I wasn't aware the order-bugs-by-id rule was a thing.


*Feature additions*: In master only.

If for some reason a feature is introduced in a branch lower than master,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This reads a bit funnily

Copy link
Member

@TimWolla TimWolla left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, except for the one remark from Ilija.

Co-authored-by: Ilija Tovilo <ilija.tovilo@me.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants