Nim: [RFC] Nim development and release model - 1.0 and beyond

[genotrance]

Based on the IRC conversations on Jan 30th, 2018, two proposals were captured for Nim's development and release process going forward.

• Trunk based development that allows for multi-version release management with a single source branch
• Branch based development which is the traditional approach of development and resorts to multiple source branches for each release

Details and pros/cons of each approach are documented here in detail.

This RFC aims to consolidate all feedback on both approaches and move towards the most appropriate release process for Nim going forward. The current inclination is to try out trunk based development since it more practical given the resources available today and already kind of how Nim is being developed today.

[timotheecour]

@genotrance thanks for the RFC; can you change wording to let users vote, eg +1 for Trunk, -1 for Branch based?

[data-man]

Poll: trunk based development

[data-man]

Poll: branch based development

[timotheecour]

I'm strongly against trunk based proposal and in favor of branch based development.
Rationale:

• not standard ; could you perhaps list major projects that use the trunk approach in the trunk proposal?

• most important point: maintaining all the {.version: "1.x.x".} will cause a lot more maintenance headache and keep in legacy code. Eg, each change will require thinking about whether to keep old behavior around with a pragma version block; this adds much complexity and will cause bugs

• packaging

  Pro : all versions in one binary available to try out - easier packaging

I don't buy this argument. Since proposal only mentions keeping 4 versions, users that need other(eg older) versions will anyway need to have an easy way to access that. Besides, unlike D where the situation is a lot more complex (split repos bw dmd,druntime,phobos ; and also split compilers (dmd,ldc,gdc)), in Nim it should be very easy to build and package a given version. Even in D there's https://github.com/CyberShadow/Digger which is as easy to use as:

digger build v2.064.2 # build a specific version
digger build "master +dmd#7757  +tools#292" # build master modified by 2 PR's against dmd and tools
# etc see docs

EDIT indeed, it's already doable and as easy as: choosenim '0.16.0'

• will make it harder to find regressions and change meaning of version 1.2.3 since 1.2.3 won't point to a fixed commit but be a moving target whose semantics/bugs could depend on code outside version pragma blocks

• nim packaging size increases (most minor point) EDITED

• proposal doesn't address fixing of bugs in LTR (long term release) versions that are beyond the limited (4) versions in trunk; for these we'll need a branch based approach anyway so might as well just use that for all versions.

• instead of version pragmas we should have feature pragmas, controlled by a flag, which are common in other languages, eg: C++ ( -fmodule ...) or D:

dmd -transition='?'
Language changes listed by -transition=id:
  =all              list information on all language changes
  =field,3449       list all non-mutable fields which occupy an object instance
  =import,10378     revert to single phase name lookup
  =checkimports     give deprecation messages about 10378 anomalies
  =complex,14488    give deprecation messages about all usages of complex or imaginary types
  =intpromote,16997 fix integral promotions for unary + - ~ operators
  =tls              list all variables going into thread local storage

[Araq]

most important point: maintaining all the {.version: "1.x.x".} will cause a lot more maintenance headache and keep in legacy code. Eg, each change will require thinking about whether to keep old behavior around with a pragma version block; this adds much complexity and will cause bugs

That is very value-able information for the documentation anyway and would need to be added manually otherwise.

Let's be honest here. Nim is still full of bugs, like many other open source projects we have a very bad quality assurance. With the branch based development model backporting bugfixes into a v1 branch would be a major pain of work for the next decade.

will make it harder to find regressions and change meaning of version 1.2.3 since 1.2.3 won't point to a fixed commit but be a moving target whose semantics/bugs could depend on code outside version pragma blocks

I don't understand this, obviously 1.2.3 would still point to a fixed commit.

not standard ; could you perhaps list major projects that use the trunk approach in the trunk proposal?

From https://trunkbaseddevelopment.com/ "Proof? Google do Trunk-Based Development and have 25000 developers and QA automators in that single monorepo trunk"

[dom96]

For what it's worth: as far as I know Rust and Swift both use the trunk-based model. Rust has adopted a concept of "epochs", see this discussion for a description: https://internals.rust-lang.org/t/evolving-rust-through-epochs/5475/4.

[Araq]

I changed my mind, I now prefer to backport the most critical bugfixes into a "last stable release" branch. Backporting can be automated by cherrypicking every commit that contains "[backport]", release building should be automatic.

[Araq]

We'll do branch based development but can review this design decision later, closing for now.

[timotheecour]

We'll do branch based development but can review this design decision later, closing for now.

see my forum post: development and release model: use the oneflow model - Nim forum [EDIT]

[Araq]

Update: Starting with the release of 0.20 we're trying the trunk based development model since we expect it to work better when we have many, many bugfixes and fewer feature additions.