Trunk-based development
- Support for multi-version release management
- Add new {.version: "1.x.x".} pragma for new procs in stdlib, be able to define when added and removed "1.1.0, < 2.0.0"
- Ship single package with multiple branches enabled - default selected is latest version of oldest supported branch
- Add nim --list-versions to show users what versions are available (include deprecation status)
- Add nim --set-version:1.2.0 to configure global nim.cfg or user to manually edit file
- Ensure all pre-existing v2.0 features behind version block/pragma
- Fix all "high priority" bugs, "regressions" and "showstoppers" in 1.0.0 code
- Remove all deprecated symbols and update stdlib accordingly
- Test all major libs and verify working with 1.0.0 version
- Release 1.0.0 as tag like existing Nim releases
- For 1.x maintenance
- If non-breaking bug fixes, fix normally
- If new non-breaking features, put inside if/when 1.x.0 version block/pragma
- For 2.x development
- If breaking features, put inside if/when 2.0.0 version block/pragma
- If 1.x breaking bug fixes, put inside if/when 2.0.0 version block/pragma
- If bug fixes in 2.0.0 code, ensure inside if/when 2.0.0 version block/pragma
- If new features in 2.0.0 code, ensure inside if/when 2.0.0 version block/pragma
- Mark any 1.x code as deprecated
- Effectively same model as current Nim releases - limited stability in 2.x-alpha until official release
- Release 1.0.x/1.x.0 depending on contents of code change
- When 2.x is ready - repeat
Open questions
- Can {.version.} be used by users? Will it be the Nim compiler version or their own software versioning?
- Yes - it will be Nim compiler version and can be used to target a package/project against multiple versions of Nim
- How many branches are supported and for how long?
- Looks like 4 versions eventually
- X-1.x.x (bug fixes only)
- X.x.x (bug fixes track)
- X.x+1.x (new non-breaking features)
- X+1.x.x (unstable initially but )
- Once X.x+2.0 is released, X.x.x should get deprecated - no more bug fixes
- Once X.x+3.0 is released, X.x.x should get removed
- Looks like 4 versions eventually
- Deprecation and removal of old versions
- Once version is no longer supported, notify user that version selected is deprecated
- When do version blocks get removed altogether?
Comparison
- Pro : one branch, no branch/merge headaches
- Pro : all versions in one binary available to try out - easier packaging
- Pro : {.version.} pragma and when version<>= allows package builders to target multiple versions in one codebase
- Pro : easy transition to branch based development should it not work out (Araq)
- Con : unusual coding/release release management process may limit core developer availability
- Con : unusual multi-release binary unlike what users are used to
- Con : effort required to deprecate and remove old versions over time
Traditional branching
Next steps
- Branch out 1.x when HEAD deemed reasonably stable
- Fix all "high priority" bugs, "regressions" and "showstoppers" on HEAD and port to 1.x branch
- Remove all deprecated symbols and update stdlib accordingly in HEAD, backport to 1.x branch
- Test all major libs and verify working with 1.0 branch
- Release 1.0.0 - tag on 1.x branch
- If bug fixes - fix on HEAD (if applicable) and backport to 1.x branch
- Release 1.0.x or 1.1.x depending on contents of code changes
HEAD
- Effectively unstable - all releases branch out of HEAD
- Remove all deprecated symbols from previous release
- When 2.0.0 is ready:
- Create separate 2.0 branch from HEAD
- Maintain 2.x.x on 2.0 branch
- Maintain 1.x.x on 1.0 branch
- HEAD is now 3.0 unstable
Comparison
- Pro : traditional approach, standard development and release management - more core developers available
- Pro : old version branches can be abandoned and they die - no effort
- Pro : backporting is relatively easy and good training ground for growing contributors
- Con : maintenance of multiple branches, merging, testing effort is more
- Con : hard transitions to trunk-based development. We will not get any experience with the "other side" (Araq)
Trunk-based development
Traditional branching