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:

• Move of all pending PR to milestone v2.1
• Add "triage-needed" label to all remaining issues
• All "triage-needed" issues moved to milestone v2.1
• Communicate on GitHub
• Communicate on Basecamp
• Meeting (RE: edited below) - 9th of October (@TuThoThai, @Aurige, @skinkie, @ue71603, @thbar) -> we decided to review & ultimately merge two PR
• Finalize First referencing class constraints #962 (comment) before 14th of October
• Finalize Required IdType fixes #471 Required IdType fixes #471 (comment) (needs work)
• Finalize Fix missing restriction attributes #975 as a follow up of Fix required idtypes #970
• Check Unconstrainted references #972 and decide which release it goes to
• Finalize Undoing restriction attributes for some complex xxxRefStructure, fixing problems in the spp,fixing a missing include in two files for VehicleRef, fixes problem with WSDL generation #976 as a follow up of Fix required idtypes #970
• Backport bug & typos changes from master to next @thbar (including documention for next release) [EPIC] Proposal for the backport of missing commits from master into next #982
• Check (and probably revise) NeTEx_publication_timetable.xsd and NeTEx_publication-NoConstraint.xsd @TuThoThai (including documention for next release)
• Rename master to v1.3
• Rename next to v2.0
• Make v2.0 branch the default one
• 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.0
• Create working branches v2.1-wip and v3.0-wip
• Clarify in the readme.md the branch management and how to contribute

[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