daily pastebin goal
74%
SHARE
TWEET

Untitled

a guest Feb 13th, 2018 54 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. **Trunk-based development**
  2. - Support for multi-version release management
  3.   - 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"
  4.   - Ship single package with multiple branches enabled - default selected is latest version of oldest supported branch
  5.   - Add nim --list-versions to show users what versions are available (include deprecation status)
  6.   - Add nim --set-version:1.2.0 to configure global nim.cfg or user to manually edit file
  7. - Ensure all pre-existing v2.0 features behind version block/pragma
  8. - Fix all "high priority" bugs, "regressions" and "showstoppers" in 1.0.0 code
  9. - Remove all deprecated symbols and update stdlib accordingly
  10. - Test all major libs and verify working with 1.0.0 version
  11. - Release 1.0.0 as tag like existing Nim releases
  12. - For 1.x maintenance
  13.   - If non-breaking bug fixes, fix normally
  14.   - If new non-breaking features, put inside if/when 1.x.0 version block/pragma
  15. - For 2.x development
  16.   - If breaking features, put inside if/when 2.0.0 version block/pragma
  17.   - If 1.x breaking bug fixes, put inside if/when 2.0.0 version block/pragma
  18.   - If bug fixes in 2.0.0 code, ensure inside if/when 2.0.0 version block/pragma
  19.   - If new features in 2.0.0 code, ensure inside if/when 2.0.0 version block/pragma
  20.   - Mark any 1.x code as deprecated
  21.   - Effectively same model as current Nim releases - limited stability in 2.x-alpha until official release
  22. - Release 1.0.x/1.x.0 depending on contents of code change
  23. - When 2.x is ready - repeat
  24.  
  25. Open questions
  26. - Can {.version.} be used by users? Will it be the Nim compiler version or their own software versioning?
  27.   - Yes - it will be Nim compiler version and can be used to target a package/project against multiple versions of Nim
  28. - How many branches are supported and for how long?
  29.   - Looks like 4 versions eventually
  30.     - X-1.x.x (bug fixes only)
  31.     - X.x.x (bug fixes track)
  32.     - X.x+1.x (new non-breaking features)
  33.     - X+1.x.x (unstable initially but )
  34.   - Once X.x+2.0 is released, X.x.x should get deprecated - no more bug fixes
  35.   - Once X.x+3.0 is released, X.x.x should get removed
  36. - Deprecation and removal of old versions
  37.   - Once version is no longer supported, notify user that version selected is deprecated
  38.   - When do version blocks get removed altogether?
  39.  
  40. Comparison
  41. - Pro : one branch, no branch/merge headaches
  42. - Pro : all versions in one binary available to try out - easier packaging
  43. - Pro : {.version.} pragma and when version<>= allows package builders to target multiple versions in one codebase
  44. - Con : unusual coding/release release management process may limit core developer availability
  45. - Con : unusual multi-release binary unlike what users are used to
  46. - Con : effort required to deprecate and remove old versions over time
  47.  
  48. **Traditional branching**
  49.  
  50. Next steps
  51. - Branch out 1.x when HEAD deemed reasonably stable
  52. - Fix all "high priority" bugs, "regressions" and "showstoppers" on HEAD and port to 1.x branch
  53. - Remove all deprecated symbols and update stdlib accordingly in HEAD, backport to 1.x branch
  54. - Test all major libs and verify working with 1.0 branch
  55. - Release 1.0.0 - tag on 1.x branch
  56. - If bug fixes - fix on HEAD (if applicable) and backport to 1.x branch
  57. - Release 1.0.x or 1.1.x depending on contents of code changes
  58.  
  59. HEAD
  60. - Effectively unstable - all releases branch out of HEAD
  61. - Remove all deprecated symbols from previous release
  62. - When 2.0.0 is ready:
  63.   - Create separate 2.0 branch from HEAD
  64.   - Maintain 2.x.x on 2.0 branch
  65.   - Maintain 1.x.x on 1.0 branch
  66.   - HEAD is now 3.0 unstable
  67.  
  68. Comparison
  69. - Pro : traditional approach, standard development and release management - more core developers available
  70. - Pro : old version branches can be abandoned and they die - no effort
  71. - Pro : backporting is relatively easy and good training ground for growing contributors
  72. - Con : maintenance of multiple branches, merging, testing effort is more
RAW Paste Data
Top