Implement version() and banner()

[ViralBShah]

We should have a version() that can programmatically query the version of julia, in a way that allows doing arithmetic on version numbers.

We should also have a banner(), which can recreate the banner printed on startup.

[JeffBezanson]

We need a scheme for numerically-comparable version numbers. How about abbcc for a.bb.cc, allowing 2 digits for minor and bugfix versions? The major version can have any number of digits.

[ViralBShah]

I was just thinking of version being a floating point number a.b, and just using regular arithmetic on it. The downside is that bugfix releases are difficult to make.

-viral

On 22-Aug-2011, at 11:34 AM, JeffBezanson wrote:

We need a scheme for numerically-comparable version numbers. How about abbcc for a.bb.cc, allowing 2 digits for minor and bugfix versions? The major version can have any number of digits.

Reply to this email directly or view it on GitHub:
#185 (comment)

[StefanKarpinski]

Perl has made every ugly mistake possible with this issue, leading to the existence of things like this.

The solution that makes the most sense is to return the version as a VersionNumber object that implements the semantic versioning specification. It can stringify the way you want it to and compare with various things the way you want it to. Here's a sketch of it:

type VersionNumber
  major::Int
  minor::Int
  patch::Int
  suffix::String
end

Comparison should work so that ver >= 1.5 where 1.5 is just a floating point number will compare as expected. It should also allow ver >= "1.5.2beta3" to work. In general, it should convert anything it compares with to VersionNumber and then do the comparison as version number objects, which is simple enough.

[ViralBShah]

Yes, I thought of a VersionNumber Type, but thought it was a bit too much pain for now. Admittedly much lesser pain than doing it in other languages.

-viral

On 22-Aug-2011, at 8:26 PM, StefanKarpinski wrote:

Perl has made every ugly mistake possible with this issue, leading to the existence of things like this.

The solution that makes the most sense is to return the version as a VersionNumber object that implements the semantic versioning specification. It can stringify the way you want it to and compare with various things the way you want it to. Here's a sketch of it:

type VersionNumber
 major::Int
 minor::Int
 patch::Int
 suffix::String
end

Comparison should work so that ver >= 1.5 where 1.5 is just a floating point number will compare as expected. It should also allow ver >= "1.5.2beta3" to work. In general, it should convert anything it compares with to VersionNumber and then do the comparison as version number objects, which is simple enough.

Reply to this email directly or view it on GitHub:
#185 (comment)

[StefanKarpinski]

This is really not hard at all. I will implement it.

[JeffBezanson]

Seems over-engineered, since it seems to me this can be solved with zero code and zero new types.

[StefanKarpinski]

Sure, zero code and zero new types, but instead, an ad-hoc "scheme for numerically-comparable version numbers", specifically:

abbcc for a.bb.cc, allowing 2 digits for minor and bugfix versions, [where] the major version can have any number of digits.

Now Julia version numbers look like 1.02.03 instead of 1.2.3, the format the open source community as a whole has converged on, and that is expressly supported by GitHub. I'll take a new type with clear semantics over a scheme most days.

We'd be making the same mistake that Perl already made. You can read some history here. I completely disagree with the author's conclusions, however: he's wrong that "version numbers are for machines, not people" — they're for both machines and people. Maybe that would be a good way to go in isolation from the rest of the world, but the thing is that the entire open source community has converged on a de facto standard that Tom Preston-Werner codified in the semantic versioning spec I linked to above.

[JeffBezanson]

No, my scheme is for encoding a version as a single number and does not affect how it is shown as a string or the meanings of the fields. "1.2.3" corresponds to "10203" as a single number and vice-versa. Basically this is a way of representing the VersionNumber type as an integer instead of as a compound type. Except for the string part, it works the same except that you don't need to define comparison since it's embedded in integer comparison.

[ViralBShah]

Also, strings such as beta can be avoided by following a linux version numbering. But all this feels a bit too kludgy, and something that can potentially seem silly 3 years from now.

-viral

On 22-Aug-2011, at 10:41 PM, JeffBezanson wrote:

No, my scheme is for encoding a version as a single number and does not affect how it is shown as a string or the meanings of the fields. "1.2.3" corresponds to "10203" as a single number and vice-versa. Basically this is a way of representing the VersionNumber type as an integer instead of as a compound type. Except for the string part, it works the same except that you don't need to define comparison since it's embedded in integer comparison.

Reply to this email directly or view it on GitHub:
#185 (comment)

[JeffBezanson]

Is it even possible to conceive of anything that won't seem silly 3 years later? :-P

[StefanKarpinski]

82bdebe adds support for semantic version numbers.

[StefanKarpinski]

Note that there's no reason for version() to be a function — instead you can just access VERSION which is a global and will eventually be constant. We already have banner() so this issue is addressed.

[ViralBShah]

Should VERSION be called JL_VERSION? Would be a good idea to not pollute the global namespace too much..

-viral

On 24-Aug-2011, at 10:40 PM, StefanKarpinski wrote:

Note that there's no reason for version() to be a function — instead you can just access VERSION which is a global and will eventually be constant. We already have banner() so this issue is addressed.

Reply to this email directly or view it on GitHub:
#185 (comment)

[StefanKarpinski]

No, all-caps globals are fine. Eventually, we'll have namespaces and this will become less of an issue.