[6.30] diverging branches of the release notes

[ferdymercury]

Explain what you would like to see improved and how.

The release notes of 6.30, see e.g. d9c7887 are diverging for master vs 6.30 patches.

Some new changes have been implemented only in v630patches, others are only added to master. As a result, it has become a bit messy, and changes that should appear on the ROOT website release notes are not appearing because they should have been backported to 6.30

On the other hand, an easy backport is not doable because new changes were done directly on 6.30patches without doing them on master, so we would need to use 'Meld' to fuse them by hand to restore a bit the order.

Are there some common guidelines for the future on this? Like 'only do changes in 6.30 branch', or 'only do changes in master and then backport'?

ROOT version

ROOT v6.30/02
Built for linuxx8664gcc on Nov 27 2023, 19:50:38
From tags/v6-30-02@
With c++ (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Binary directory: /opt/root/bin

Installation method

Binary Release

Operating system

Ubuntu 22.04

Additional context

No response

[vepadulano]

Are there some common guidelines for the future on this? Like 'only do changes in 6.30 branch', or 'only do changes in master and then backport'?

I don't think we have a guideline yet for this very specific case. I think in practice, for the majority of cases we try to merge changes in master and then backport.

[ferdymercury]

Are there some common guidelines for the future on this? Like 'only do changes in 6.30 branch', or 'only do changes in master and then backport'?

I don't think we have a guideline yet for this very specific case. I think in practice, for the majority of cases we try to merge changes in master and then backport.

Let's imagine an example. I fix an issue for 6.32, and it is automatically collected and added to the 6.32 Release Notes. Furthermore i add a custom message to 6.32relnotes in the e.g. roofit section. I then backport the fix to 6.30. However, this time, the custom message in relnotes will not be automatically added to the 6.30 Release Notes because it was already released. So, after backporting the fix from master to 630, should one:

a) Create a new PR for the 630_ReleaseNotes file, but on the master branch and then after merging, backport it to 6.30 branch
or
b) Create a new PR for the 630_ReleaseNotes file and forget about the master branch, which will stay with an outdated version of 630-relnotes, which is however not very critical since the RelnotesWebpage for 6.30 is built from the 630 branch and not from master?

[pcanal]

it will not be automatically added to the 6.30 Release Notes because it was already released

This might not be specific enough. The release notes for the already released version of v6.30 (let's say v6.30.04) are frozen by definition. However the fix should be properly pickup by the release procedure for the next version, i.e. v6.30.06. (of course this require adding the proper tag to the issue). What am I missing?

[ferdymercury]

it will not be automatically added to the 6.30 Release Notes because it was already released

This might not be specific enough. The release notes for the already released version of v6.30 (let's say v6.30.04) are frozen by definition. However the fix should be properly pickup by the release procedure for the next version, i.e. v6.30.06. (of course this require adding the proper tag to the issue). What am I missing?

Thanks for the message.
True, but I did not express myself well (edited now above message). I am not speaking only about the automatic fixed issues collection protocol. I am speaking about manual additions to the release notes where a more in-depth message is written. In that case, there is the ambiguity of where this should be added, in the 63006relnotes of master and then backport to 630patches, or rather directly in 630patches. Right now, we have a bit of everything. If you use 'meld' to compare them, you will see the issue more clearly.

[dpiparo]

I propose to close this issue as clarified: I agree that the solution is to make backporting as easy as possible (#14889) to avoid these cases. We can focus our attention to the automation.