**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
- 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
- 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