genotrance/next.md

## next.md

      
    Raw
  

              next.md
            
          
    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
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)