The question of backport & CI

[TuThoThai]

In reply to this comment in PR #1064, here is some context & guidelines for the management of backport and why it was included in the CI.

What happened during the release of v2.0.0

• @thbar and I realised there were numerous commits on master that were not backported into next
• The detailed list can be found in issue [EPIC] Proposal for the backport of missing commits from master into next #982
• Since it was the job of maintainers to handle backports, @thbar and @TuThoThai handled them with the great support of @skinkie and @ue71603 to solve conflicts between the 2 branches
• The workload was at least 5 days (probably closer to 7 if we count hours from @skinkie and @ue71603)

What has been decided

• The creation of a CI check for backport by @thbar --> PR Make sure PR cannot be merged, if their base branch is not up-to-date itself (avoids #982) #1022
• PR was merged after approval by @skinkie, @ue71603 and @TuThoThai

What has happened since

• Branches were renamed v2.0, v2.1-wip, etc. to simplify work and allow parallel improvements (i.e., getting away from master and next)
• It has been approved that bug fixes and typos can still target v2.0
• Backports of commits done to v2.0 tov2.1-wip should be done by either the author of the PR or maintainers team on regular basis
• Such principles were applied with backports handled by @TuThoThai in PR Backport changes from v2.0 to v2.1-wip #1045, Backport changes from v2.0 to v2.1-wip-efip #1046, Backport to v2.1-wip -- Addition of AI guidelines in the readme (#1050) #1051

As of today

• The only remaining commit in v2.0 is 482a533
• Since it was authored by @ue71603, out of convenience I decided to include it in the latest PR by the same author --> PR Update netex_nm_equipmentEnergy_support.xsd #1060

My personal thought: I agree that me going with convenience is not 100% correct, but it was the fastest considering there is only a single commit.

Your thoughts @thbar, @skinkie and @ue71603?

[ue71603]

I think in the new individual PR ist should be a warning and not something that is breaking. Because what needs to happen is that 2.0 is merged into 2.1-wip. And this is done by the maintainers.

The problem before was that the two lines were separated for months to years. So I guess periodically 2.0 -> 2.1-wip.
But that are my 5 cents..

One can decide if individual PR can be merged into 2.1-wip before 2.1-wip is updated or not. I think that depends on the complexity.
If we do something in 2.0 that is huge and has implications then immediately 2.1-wip should be adapted as well.