since now takes an optional patch, eg: since: (1, 3, 1)

[timotheecour]

This PR makes it a bit easier to use NimPatch by supporting both since (1,3) and since (1,3,1).
see tests in tinclrtl.nim

NimPatch is underused (since 1.0 was release), but is useful even after 1.0 was released.

• It allows writing portable code in between "official" nim releases even if switching branches/versions/commits.
  For example, I can have in my user config.nims (or regular code) conditionals like
  when (NimMajor, NimMinor, NimPatch) >= (1, 3, 3): useNewFeatureX() else: useWorkaroundForX()
  and it'll work regardless which branches/versions/commits I'm on.
  note that when declared(foo) won't work with overloads, and when compiles has known caveats and won't work when inner logic changes

• it reduces (but doesn't elimitate) the need for introducing new define symbols in compiler/condsyms.nim

• it's self-documenting when a feature/symbol was introduced

[Araq]

But introducing new symbols in a patched version is completely against semver so what's the point?

[timotheecour]

branching can occur for other reasons than symbol additions and take advantage of since sugar eg since (1,3,3): foo() # eg a bugfix happened in foo

But the main point is this: we're already breaking semver inside devel branch (ie, NimMinor is odd) each time we merge a PR that introduces a symbol.
Depending on which commit/branch/PR you're on in devel, symbol X may or may not be declared, even though we're still at (NimMajor, NimMinor) = (1,3).
With the above logic, tagging (1,3,3) would never make sense as we're fixing bugs and introducing new symbols all the time in (1,3) branch.

So instead of having a completely meaningless NimPatch on devel branch hardcoded forever at 1, we can give it a useful meaning, and bump it as needed when a new symbol is introduced or whenever branching makes sense for client code.

This has no impact on official nim releases (ie NimMinor is even, like 1.2.X), for which semver can be respected.

example

#13606 changed the meaning of --listcmd, turning it into something more meaningful/consistent (eg, in combination with --hint:link:on, would print the link command); so I'm keeping it on in my ~/.config/nim/config.nims; but before that PR, --listcmd would print C compilations, resulting in very verbose logs; so I had to keep switching on/off that option each time I changed branches / commits, since there was no way to distinguish based on patch version.

With my proposal, this would've been easily fixed by bumping NimPatch: NimPatch+=2 in that PR or a fixup PR (eg: (1, 1, 1) => (1, 1, 3)) so that I can branch:

# in ~/.config/nim/config.nims
when (NimMajor, NimMinor, NimPatch) >= (1, 1, 3): switch("listCmd", "on") 

Obviously it's not limited to your user config, that was just 1 concrete example to illustrate.

why bump via NimPatch+=2 instead of NimPatch+=1 ?

that aspect is not as critical and independent of above discussion.
It allows following use case: allow releasing frequent best-effort "un-official" nim releases on devel branch, tagged at 1.(2x+1).2y (eg 1.3.12) for convenience for users who want to get a recent version of nim without building from devel. We make explicitly zero promises wrt breaking changes for those unofficial releases.

docgen uses NimPatch mod 2 == 1

docgen logic may need to be updated accordingly to reflect whatever chosen rules are; currently it's using: # from `NimPatch mod 2 == 1` to `NimMinor mod 2 == 1`.

[narimiran]

IMO, things are fine as they are currently. No need to complicate them just to fit somebody's complicated workflow. KISS.

This gets thumb down from me.

[zah]

Seems like a no-brainer to me. This indeed helps tracking additions to the devel branch before they are released.

[Araq]

Ok. I hope it means we can stop adding nimHasX cruft to condsyms.nim.