daily pastebin goal
48%
SHARE
TWEET

Untitled

a guest Feb 13th, 2018 55 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
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
 
Top