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
  preparations for IC+ORC Nim#17814
• IC: stable
  https://forum.nim-lang.org/t/8627#56050
  preparations for IC+ORC Nim#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
  User-defined implicit initialization hooks #252
• threads=on: enabled as default
  [RFC] switch threads to on by default #361
  https://forum.nim-lang.org/t/7983#53496
• unsafeAddr == addr
  Deprecate 'unsafeAddr' and make 'addr' available for all addressable locations #369
  https://forum.nim-lang.org/t/7983#50901
• extract some modules into nimble packages
  https://forum.nim-lang.org/t/7983#50901
  How to treat versions of the stdlib and external packages #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:
#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.