First, why haven't there been any full devel 1.3.5 releases including Linux x64 and OSX for the last month since the 11th of May this year? There have been lots of releases but they haven't been "full", only including various ARM versions for Linux and no versions for OSX, at least pre-compiled versions which kind of implies that these versions can't be compiled for these Linux and OSX targets.
Second, I thought I understood the Nim version numbers as having odd numbers when being developed and even numbers when stable; thus 1.0.6 and 1.2 0 are stable but 1.2.1 is not but is a development version of a future possible 1.2.2 which would be a version including relevant bug fixes and back ports.
What confuses me in the repo version numbers is that occasionally we get a version 1.0.7 which would imply that there will eventually be a 1.0.8 even though most are using the (mostly) stable 1.2 and waiting for either a minor update to 1.2.2 or a major update to 1.4.0 (or higher), which is what the version 1.3.X versions will become.
Also, the current devel branch went from 1.3.1 to 1.3.3 to current 1.3.5 even though there have been no stable releases inbetween, although I suppose that might somehow be tied to the state of back ports to the previous versions. This isn't so much of a problem as the highest number is probably always the latest devel.
As an observation, this "odd = unstable" kind of makes sense even as applied to major versions 1.0, 1.06, 1.2, etc., as there are so many anticipated changes related to using gc:arc to make threading more usable that these versions could almost be considered to be semi pre-final non-breaking changes versions, at least if one wants to get away from using GC in Nim but doesn't want to drop down to full unmanaged memory as I really want to see the language able to do in a stable version.
I'm starting to feel that Nim can't be regarded to be fully stable until it approaches version 2.0, whether that includes owned/borrowed/lent on references or not, as it seems that implementing gc:arc has been much more complex than anticipated, what with having to support so much legacy code.
I'm sorry that I haven't been able to help more with --gc:arc implementation, which is too complex for my limited computer science background: my background is enough so I can follow as fixes are made but not be competent enough to contribute effectively. I am preparing some tests that will fully tax gc:arc when I feel it is ready, but until then have fallen back to mostly using unmanaged memory for threading, as that is adequate for most of the things I do to show that Nim is effective as a systems level language. However, for most of this there is no reason that the memory management can't use --gc:arc reference counting as the overhead will be minimal and the resulting code would be cleaner.
It's like this:
1.0 is our long-term support (LTS) stable release. While 1.0.N is in development the version is 1.0.(N-1). The reason that 1.0.7 exists in our branch is that there will be a 1.0.8. Because 1.0 is the version we support for the upcoming X (X = 5?) years.
1.2.0 is the first release that ships --gc:arc. 1.2.2 will be released soon having many arc-related fixes and also other fixes we seemed important enough to backport. Probably there will be no version 1.2.4 because 1.2.0 isn't an LTS release.
1.3.x is the development version that will become 1.4.0. For technical reasons having to do with bootstrapping the x is more frequently updated these days. It's expected that 1.4.0 will ship --gc:arc with the cycle collector.
Regarding arc being hard to implement, well, it's still automatic memory management and it works with threading so there is some intrinsic complexity involved. Everything should be made as simple as possible, but no simpler.
1.2.0 is the first release that ships --gc:arc. 1.2.2 will be released soon having many arc-related fixes and also other fixes we seemed important enough to backport. Probably there will be no version 1.2.4 because 1.2.0 isn't an LTS release.
At Status, we are eagerly waiting for 1.2.2 and will freeze our codebase on 1.2.2 with a 4 months long audit of our Ethereum 2 code that will start before the end of the month (announced here). During that time and until we decide that we have sufficient incentives to move to 1.4.x or later we will stay on a 1.2.x branch.
This in particular means that our libraries will be battle-tested for 1.2.x but not for 1.4.x, this might be important for GUI tooling as our desktop team is building a new desktop UI in Nim+QML at https://github.com/status-im/nim-status-client.
I.e. if we uncover showstopper bugs on 1.2 we hope to have a 1.2.4 release with the fixes.
I.e. if we uncover showstopper bugs on 1.2 we hope to have a 1.2.4 release with the fixes.
Well surely you will get a 1.2.4 if you need one.
@araq, thanks for the quick reply regarding version numbers; I get it.
If you regard Nim as incomplete without arc then that's fair but it's not the same as unstable.
Yes, that's what I mean: it's incomplete.
How about the first part of the question on why there have been no OSX or Linux x64 devel 1.3.5 compiled releases for over a month? Does that mean there are problems compiling to these two targets?
Does that mean there are problems compiling to these two targets?
No, there are currently problems with the nightly builds but nim devel is green on all major OSes including BSD.
@araq:
No, there are currently problems with the nightly builds but nim devel is green on all major OSes including BSD.
Thanks, good to know.
Any idea when the nightly builds might be up to speed, as some online IDE's such as Wandbox only update their devel option when the nightlies are updated.