fusion: design discussion

[timotheecour]

allowed dependencies

• nim bootstrap (building nim from csources) and then building koch should stay isolated from both fusion and nimble (ie, nim c koch should not depend on any nimble package; but maybe nim c -d:nimkochenablefusion koch would be acceptable if needed later)
• koch boot should also not depend on fusion nor nimble
• ./koch tools can then install nimble, which can then do nimble install fusion; the fusion version (eg fusion@0.2.6) should be baked in koch and tied to a nim release, just like it is for koch tied to a particular version of nimble
• anything after that point can depend on fusion, in particular testament, compiler, tools
• when possible, prefer depending on fusion than some other nimble package

versioning

• nim's release schedule should be indendependant of fusion's release schedule; but a nim version specifies (hardcoded in koch, see above) what version of fusion is needed for bootstrap
• we can adopt nim's version scheme to fusion; it really makes sense to distinguish stable from devel; this allows making necessary breaking changes in development (odd) versions (in between stable versions)
• IMO we should downgrade fusion version to 0.1, too early for 1.0 (whatever that means); we haven't even nailed down important details

testing fusion against nim devel and vice versa

• devel nim tests for compatibility with fusion at fusion's latest release tag
• devel fusion tests for compatibility with nim at nim's supported versions (latest release tags in 1.0.X, 1.2.X) + latest devel tag (1.3.5 => nimPatch should be upgraded often)

staging and experimental API's

It's hard to get API right the 1st time (chicken egg: not released => no user => no feedback) so we need a way to allow users to test out an API knowing that the API may change. The rule is:

• if an experimental feature is introduced, its API may change but the feature in general should not disappear; changelog should describe how to migrate code to newer API
  There are several approaches:

• fusion/experimental/mylib
  somehow araq is against it, but it helps during inital design of a new module; it's the difference between a 1 person project (a PR/branch) vs a collabative project (multiple ppl can improve

• fusion/mylib, fusion/mylib2, fusion/myli3, ...
  IMO that makes sense on a bigger time scale, but not during early development

• fusion/mylib with when defined(nimMylibHasFoo)
  this scales well and is analog to --experimental:X feature in nim compiler. It can even be at entire module scope, eg during inital development of a module

naming conventions

• if std/os exists in stdlib, fusion should start at 2 eg: fusion/os2, not fusion/os; this makes transision easier if fusion/os2 is ever merged back to stdlib

good fusion candidates

• io2
• os2 (rfc in progress)
• osproc2 (including independent stdin/stderr/stdout streams; more on this later)