Mirror of forum.nim-lang.org

5606 :: Nim 1.0.4 is out!

• federico3 (orginal) [2019-11-27T23:23:33+01:00] view original

  Blog post: https://nim-lang.org/blog/2019/11/26/version-104-released.html

  (The Debian package is currently uploading and the Ubuntu one will follow)

---

• ducdetronquito (orginal) [2019-11-28T09:31:12+01:00] view original

  Do someone know the reason why we skipped the release 1.0.1 and 1.0.3 ?

---

• Stefan_Salewski (orginal) [2019-11-28T09:49:19+01:00] view original

  Nim uses odd minor version numbers to denote development releases and even minor version numbers to denote stable releases. That is common practice, see

  https://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_development_releases

---

• sschwarzer (orginal) [2019-11-28T11:01:25+01:00] view original

  That is common practice, see https://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for_development_releases

  I wouldn't conclude from the Wikipedia section that it is common practice, at most that it was common practice. ;-) I think not using the gaps and using suffixes instead is much more direct.

  See also https://semver.org .

  Just saying. I can live with Nim stable "skipping odd versions", but the versioning scheme still feels a bit odd. (couldn't resist the pun :-) )

---

• Araq (orginal) [2019-11-28T11:54:55+01:00] view original

  This is how you can do a version check in Nim; when (NimMajor, NimMinor) >= (2, 2). I don't even want to know how it would work with "version suffixes". Encoding semantics as a tuple of numbers is already silly enough, adding even more junk on top of it like "-rc1", "-beta" is not gonna help the tooling. Personally I would simply use the release date as the version, this way you can do more meaningful comparisons like "Nim-2014 probably wasn't tested against GCC-2019 all that much..."

---