version-2-0 branch and CI

[quantimnot]

Create a version-2-0 branch that PRs can be opened against. All CI tests of the compiler, tools, and stdlib should pass. Compatibility tests should be formed from set of community packages. All compatibility tests should be advisory and not fail the CI result. The compatibility tests should help identify migration routes and document breaking changes.

Big friction point: PRs for devel would have to be forward-ported to the version-2-0 branch.

[Araq]

I think we need to decide whether the devel branch should be 2.0 already.

[dom96]

I would move fast here, the quicker we have a version-2.0 branch the quicker we can start making PRs against it with breaking changes. Merging devel into it shouldn't be too bad.

[quantimnot]

From the standpoint of someone who hasn't dealt with this sort of thing: I think making current devel be for 2.0 is the right move. It would have less distraction and time/energy forward porting PRs. And there seems to be lots of eagerness for a 2.0 (not necessarily a good reason).

I searched for comments mentioning changes for 2.0.

Araq, you state your main goals as:

not let the perfect be the enemy of the good

• ORC: stable and default https://forum.nim-lang.org/t/7983#50901 https://forum.nim-lang.org/t/8627#56065 https://github.com/nim-lang/Nim/pull/17814
• IC: stable https://forum.nim-lang.org/t/8627#56050 https://github.com/nim-lang/Nim/pull/17814
• not-nil: bugfixes, but still experimental https://forum.nim-lang.org/t/7457#47320
• views: bugfixes, but still experimental https://forum.nim-lang.org/t/7457#47320
• concepts: bugfixes, but still experimental
• initializers https://forum.nim-lang.org/t/7727#49027 https://github.com/nim-lang/RFCs/issues/252
• threads=on: enabled as default https://github.com/nim-lang/RFCs/issues/361 https://forum.nim-lang.org/t/7983#53496
• unsafeAddr == addr https://github.com/nim-lang/RFCs/issues/369 https://forum.nim-lang.org/t/7983#50901
• extract some modules into nimble packages https://forum.nim-lang.org/t/7983#50901 nim-lang/RFCs/issues/371 https://forum.nim-lang.org/t/3772
• new modules use concepts (does that imply concepts would be non-experimental?) https://forum.nim-lang.org/t/7983#50901
• refactor os -> errors, envs, paths, dirs, files, syms https://forum.nim-lang.org/t/7983#50901
• refactor json -> builder, parser, lexer, tree, mapper https://forum.nim-lang.org/t/7983#50901

I noticed threading being a theme in discussions:

• maybe new threadpool https://forum.nim-lang.org/t/7983#52533

I also notice many users interested in lazy semantic symbol checking: https://github.com/nim-lang/RFCs/issues/416 (more references needed)

Regarding CI: A set of community packages are already tested against, so no change there other than ensuring they are only advisory.

I guess the actions are:

• compile official list of 2.0 goals
• create missing tracking issues/draft PRs
• add issues to a 2.0 milestone
• maybe create issue/pr labels like "breaking change", "deprecation", "extract to package"
• write/publish announcement of intent

P.S. I didn't know whether the RFC repo is the correct location for this issue. Is it?

[Araq]

See also https://forum.nim-lang.org/t/8627#56143

[metagn]

An officially designated "devel is 2.0" period with a set end date of maybe at least a couple months that can maybe be extended would be very much appreciated on behalf of contributions. I am also wondering if 1.6 or any following version is going to be the LTS of the 1.0 line. I'm guessing it is 1.6, but just to make sure. Backports would need to be more common if this is the case but I don't think there would be enough to warrant a version-2-0 branch.

[Araq]

I am also wondering if 1.6 or any following version is going to be the LTS of the 1.0 line. I'm guessing it is 1.6, but just to make sure.

Yes, I can confirm that 1.6 is the LTS of the 1.0 line.