Upcoming v2.0 Development and Release Process

[shaselton-usds]

Exciting news, everyone!

I wanted to take this time and space to outline the upcoming development process for the TiC schema v2.0 updates and changes. The overall goal of this post is to outline the proposed development, branching, merging, and release strategy for v2.0, and to gather feedback from the community and contributors. We want to ensure a smooth transition and maintain stability for v1.x while building a robust v2.0. Throughout this process, just as with v1.0, we encourage your questions, comments, and suggestions.

Background

With the recent EO (more information can be found in this discussion #777), we are excited to implement many updates to the schema to create a v2.0 that we've been contemplating for some time now. Much of these updates have come from current v1.x MRF observations and stakeholder feedback from many of you. Moving major versions (in this case from v1 to v2) typically introduces breaking changes across the schema/software versions. While this can cause challenges in ensuring files are correctly developed, the proposed updates bring significant improvements in performance, architecture/file-structure, and address long-standing limitations. The Department's goals with these updates are to minimize file content duplications, encourage a reduction of overall amount of files, and make the data within the file more immediately actionable.

Development Process: Branching and Isolation

The main goal during this time is to keep v1.x stable while v2.0 is under development. While this process generally follows standard development lifecycle practices, minor deviations may occur. You can expect development to largely emulate the following:

Branching Strategy

Master Branch

• The master branch will continue to host the stable v1.x schema for all of the MRFs.
• Only critical bug fixes and security patches will be merged here (resulting in either a minor/patch release if needed) that will result in a new tag.

Develop Branch

• The develop branch will continue to be the staging branch for master and the current v1.x.

v2.0 Development Branch

• develop-v2 will be the primary development branch for v2.0 updates.
• All new features, breaking changes, and v2.0 updates will be committed to (or merged into) this branch.
• Feature branches for individual v2.0 updates will be created off develop-v2 and merged back upon completion and review.
• The first sets of updates can be found in this branch currently.

Release Candidates (RC) and Final v2.0.0 Release

• When the develop-v2 branch is deemed production-ready, a release candidate (e.g. 2.0.0-rc.1) will be cut from develop-v2.
• These RCs are intended for final review and testing.
• Once the RC is stable and passes all final checks, the develop-v2 branch will be merged into master.
• The master branch will be tagged as v2.0.0 and a new release will be cut.

Considerations for Developers and Stakeholders

As previously mentioned, major version updates typically involve breaking changes, and v2.0 is no exception. We strongly encourage you to leverage the TiC schema validation tool throughout this process to ensure your MRFs comply with the new schema requirements. The validator can be downloaded and used as part of your MRF CI/CD pipeline.

Timeline

A v2.0.0 release is targeted to be cut on October 1, 2025. Required implementation of v2.0.0 is expected on February 2, 2026. By having transparency into the development process leading up to final release of v2.0.0, development for v2.0.0 MRFs can start well before October 1, 2025.

Closing Thoughts

We welcome your thoughts and questions on this process as well as your involvement with the development of v2.0.0. Thank you for any and all of your contributions in this next phase of development.