Hi All,
I merged PR 1952.
For new PRs please add CHANGELOG entries for changes that need to be made
(more) visible to users.
Thanks,
Dmitri.
On Thu, Jun 26, 2025 at 4:02 PM Dmitri Bourlatchkov
wrote:
> Here's a PR to implement what was discussed in this thread. Please review:
>
> https://gith
Here's a PR to implement what was discussed in this thread. Please review:
https://github.com/apache/polaris/pull/1952
Cheers,
Dmitri.
On Mon, May 19, 2025 at 5:54 AM Robert Stupp wrote:
> +1 on having a CHANGELOG. That's been proven to be very useful.
>
> Change-log and release-notes (as a li
+1 on having a CHANGELOG. That's been proven to be very useful.
Change-log and release-notes (as a list of all commits) are orthogonal
IMO. The former, as Dmitri mentioned, accumulates important changes in
categories (highlights, breaking changes, new features, fixes). The
latter is a "list of
Yes but I mean that the content is already in the release notes.
So let’s do it :)
Regards
JB
Le ven. 16 mai 2025 à 16:47, Dmitri Bourlatchkov a
écrit :
> I'm proposing CHANGELOG not as a replacement for Release Notes, but as
> a method for accumulating important notices as PRs are merged betw
I'm proposing CHANGELOG not as a replacement for Release Notes, but as
a method for accumulating important notices as PRs are merged between
releases.
CHANGELOG could be used as input into Release Notes (or standalone).
Cheers,
Dmitri.
On Fri, May 16, 2025 at 9:42 AM Jean-Baptiste Onofré
wrote:
The release manager can organize the changelog but he can’t populate it.
Only the authors of the change can (with the reviewer).
Generally speaking, I think we can be helped by a PR label that can
pre-populate the changelog. But changelog or label has to be set by the
original author.
Honestly, n
There is some manual overhead, but I think the alternative is worse
(breaking changes go untracked). It's a good idea to have an ongoing
changelog like this, and I don't see a way to manage it other than manually.
Your point around consistency is an important one. The example in the
linked Nessie
It does seem to introduce quite a bit of manual overhead. I’m personally
not a big fan of that, but I’m open to trying it out. That said, I believe
the release manager should have the ability to organize the changelog at
release time, since it’s quite difficult to maintain consistency from the
pers
Hi Dimitri
It's a good idea.
I think each committer should be responsible to update the CHANGELOG
if appropriate, and reviewer should point it out if needed.
It's the same as documentation, license update and header (when code
is copied from another project), etc.
Regards
JB
On Thu, May 15, 20
Who should own that consistency? Should the release manager normalize
entries at cut time, or should each PR author follow a template up front?
I'd think it's the reviewers' (committers') duty to ensure consistency.
PR authors are encouraged to add entries to CHANGELOG as needed,
but reviewers s
These seem like good ideas to me. I'd prefer things with minimal human
interactions in the loop but
having dev emails for changing intra-release breaking commits sounds good
to me.
On Thu, May 15, 2025 at 2:30 PM Yufei Gu wrote:
> Thanks for kicking this off, Dmitri—great idea!
>
> Looking at t
Thanks for kicking this off, Dmitri—great idea!
Looking at the current CHANGELOG, the entries range from PR-number
references to detailed feature write-ups and even small tweaks like “make
test less flaky.” To keep it useful, we probably need a consistent format.
Who should own that consistency?
Hi All,
As discussed in the community sync today, Polaris evolves quickly and
breaking changes are a reality we have to live with :)
However, I'd like to propose improving user and developer experience by
keeping a change log with a section for breaking changes.
We follow this practice in Nessie
13 matches
Mail list logo
