Milestone v2.0 -- Release ongoing

[TuThoThai]

Group agreement on plenary as of 23 Sept 2025:

• NeTEx v2.0 should match the documentation shared with CEN for vote (as much as possible)
• No added functions or changes compared to the documentation
• Favour early merges, even imperfect, to get more working time for v2.1 and v3.0-

Process for the release v2.0:

• [x] Move of all pending PR to milestone v2.1
• [x] Add "triage-needed" label to all remaining issues
• [x] All "triage-needed" issues moved to milestone v2.1
• [x] Communicate on GitHub
• [x] Communicate on Basecamp
• [x] Meeting (RE: edited below) - 9th of October (@TuThoThai, @Aurige, @skinkie, @ue71603, @thbar) -> we decided to review & ultimately merge two PR
• [x] Finalize #962 (comment) before 14th of October
• [x] Finalize #471 https://github.com/NeTEx-CEN/NeTEx/pull/471#issuecomment-3385792238 (needs work)
• [x] Finalize #975 as a follow up of #970
• [x] Check #972 and decide which release it goes to
• [x] Finalize #976 as a follow up of #970
• [ ] Check (and probably revise) NeTEx_publication_timetable.xsd and NeTEx_publication-NoConstraint.xsd
• [ ] Backport bug & typos changes from master to next
• [ ] Check any conflicts
• [ ] Resolve conflits
• [ ] Merge next to master
• [ ] Communicate on basecamp & GitHub that "things are frozen" and this is the last chance for testing (but advertising that breaking changes are here)
• [ ] Prepare some copy (explaining the release for consumers)
• [ ] Make release & tag v2.0

[ue71603]

As I mentioned many times, I would like to see also release-branches( based on the commit).

• The tag we should use for master before switching is 1.3.2 (1.3.1 was EPIAP).
• We should have a branch named release/1.3 (which contains the same as master at that point
• release/2.0 which is the new branch for the release. If we have a 2.0.1 we do this in the release/2.0 branch
• The tag should be labeled release2.0.0
• We also need a tag for release1.3.2
• Master starts at the same place as release/2.0.0 and works toward release 2.0.1
• next starts from the same point as release/2.0.0 and works toward release/2.1.0
• master starts now also from release/2.0.0

We should start clarifying stuff further:

• Bugfix PR start with bug/ in the branch name and target master (or one of the release branche, if necessary)
• Feature PR should start with feature/ in the branch name target next
• All PR should possible be created directly in the REPO (allows the tools to be running).

[ue71603]

Finalising release/1.3.2 should be done before merging next into master. Building tag release/2.0, tag v2.0.0 and release zip should be done just after merging next into master

[skinkie]

I do not accept this status. Because the next argument would be "we cannot break changes in the 2.1 release" hence, everything should get merged now before a release that matches the documentation.

[Aurige]

Just as a reminder I announced that we would freeze the model in December 2024, targeting February 2025… We gradually slipped the timeline, for the same reasons that we are discussing these days. I formally requested that all requests for milestone 2.0 be stopped by the end of May—then clarified this again in June and July, especially with the announcement that documents would be submitted in the first half of July. In reality, there’s no reason to stop improving things, but we do need clear milestones in our work. And we need a proper version to face the CEN document.

[skinkie]

The model is not changing with the work that was deliberately delayed after everything else was merged.

[Aurige]

Yes but we can have the same argument for most cleaning, hygiene, bug fix, etc. We will continue doing this for a long time: we have to, and there is no intention to prevent it. But from time to time we need to freeze a version.

[skinkie]

I am not taking this answer. It does not make any sense. Model does not change, was decided by the group it would significantly improve the overall model quality.

[thbar]

Update: the meeting occurred, I've updated the top-level plan on which we all agreed.

Re branches, we should probably make a little session to come to an agreement (& turn it into documentation).

Next steps: 2 PR to finalize, then a freeze/testing session, then release!

[TuThoThai]

Upate as of 10 Oct 2025: PR #962 was merged (simple merge) @skinkie can go ahead with the rework of PR #471

[skinkie]

@thbar @TuThoThai do understand that with the IdType fixes, no extra xsd:unique constraints were introduces while I can prove they are missing. The same goes for xsd:keyrefs.

I have a clear vision how this should be approached from a NeTEx 3.0 perspective. For me not a showstopper.

[skinkie]

@thbar @TuThoThai also be aware that NeTEx_publication_timetable.xsd and NeTEx_publication-NoConstraint.xsd have not been updated. I guess the latter one is 'easy' to achieve.

[TuThoThai]

As of 20 Oct 2025, PR #975 has been merged. Addition of the revision needed for NeTEx_publication_timetable.xsd and NeTEx_publication-NoConstraint.xsd before the release

[skinkie]

@TuThoThai decide if you want to have #972 because that should be before the things you mention.

[TuThoThai]

@TuThoThai decide if you want to have #972 because that should be before the things you mention.

#972 has been addressed via PR #979, both going into v2.0 Only pending is cross-checking #976

[TuThoThai]

As of 12 Nov 2025:

• All PRs have been merged
• Support is needed from @Aurige, @ue71603, @trurlurl, and @skinkie to cross-check NeTEx_publication_timetable.xsd and NeTEx_publication-NoConstraint.xsd before we start the backport