F# 2017

[financial-engineer]

F# 2017

I suggest we start to name the F# language releases officially after the year in which they are released, e.g., F# 2017, 2018 etc.
The existing way of approaching this problem in F# is to name the F# language releases after version numbers, e.g., F# 3.0, F# 4.0, F# 4.1 etc.

Version numbers do not convey any idea to potential language users who are outside the F# community thus far. They offer absolutely no inducement to such programmers even to google information about F#, not to speak of learning the latest F# language release and of using it in their new projects. The potential language users cannot answer simple questions, while looking at the language release name: "Is it modern, cool or not? Is it worth to learn it? When did that F# release appear? F# 3.0, 4.0?". In 2012, 2016 or in 1970s or 1980s? Nobody outside the F# community knows. Really. By contrast, the year of release can say a lot to potential language users, especially when at some future date they find it in a book title, for example, "Visually stunning, distributed applications using WPF, WCF in F# 2017."

ADDED on Jan. 18, 2017 to address rmunn's criticism: I think the release name and the release number should be regarded as completely separate concepts (just like these concepts are used for Visual Studio releases: it is officially named as Microsoft Visual Studio 2015, but in Help/About you can read its version number: 14.0.23107.0).

ADDED on Jan. 18, 2017: The release name (e.g., F# 2017) should be used in marketing and PR materials on websites, in new books on F#, just because the year-based release name is more expressive to potential new users than plain version numbers.

ADDED on Jan. 18, 2017: The release number from 0.0.0.0 to 4.3.1.0 and so on should continue to be used in FSharp.Core version numbering, so absolutely nothing need to be redone in terms of software.

ADDED on Jan. 18, 2017: The F# language specification should specify that it defines, for example, F# 4.3.1.0, hereinafter referred to as F# 2017, and should refer to F# as F# 2017 in the rest of its text.
As to previous language releases, I suggest mentioning them in documents as follows: F# 2005 (1.x), F# 2010 (2.0), F# 2012 (3.0), F# 2013 (3.1), F# 2015 (4.0).

Some competitors have already used the suggested naming convention for language releases (C++14, Ada 2012, SPARK 2014, just to name a few).

Pros and Cons

The advantages of making this adjustment to F# are

• To frame the F# as a cutting-edge, modern programming language in the eyes of programmers who have never heard of it.
• To offer a strong inducement to the programmers outside the F# community to learn the latest F# language release and try using it in their new projects.
• To widen the F# community and increase the F# popularity. The 29th place in the TIOBE language popularity index as of December 2016 is not the place F# deserves. It deserves to be a mainstream (TIOBE TOP20) language. In my opinion, it needs some improvements in syntax, more tooling support, and a new naming convention for the future F# language releases.

The disadvantages of making this adjustment to F# are

• To stop promoting F# as something intended for data analytics payloads only. The existing naming convention (F# 4.0, 4.x etc.) is acceptable to math and tech experts only, but it narrows the target auditory. We need to improve grass-roots outreach efforts by employing a new naming convention suitable for more wide target auditory and conveying an idea of F# as a modern, common-purpose language.

Extra information

Estimated cost (XS, S, M, L, XL, XXL): XS (The F# language specification text (and new materials promoting F# on the Microsoft website) should be changed only).

Related suggestions: no

Affadavit (must be submitted)

Please tick this by placing a cross in the box:

• This is not a question (e.g. like one you might ask on stackoverflow) and I have searched stackoverflow for discussions of this issue
• I have searched both open and closed suggestions on this site and believe this is not a duplicate
• This is not something which has obviously "already been decided" in previous versions of F#. If you're questioning a fundamental design decision that has obviously already been taken (e.g. "Make F# untyped") then please don't submit it. It is not a fundamental design decision, it is a fundamental PR decision.

Please tick all that apply:

• This is not a breaking change to the F# language design
• I would be willing to help implement this
• I or my company would be willing to help crowdfund F# Software Foundation members to work on this

[rmunn]

After thinking it over, I've decided I'm 👎 on this proposal.

First, I disagree that the cost would be XS. I'd rate it at an L, maybe even XL. It's not just F# version numbers that would need to change, it's the whole NuGet package ecosystem that's been built around the FSharp.Core version numbering scheme. All those binding redirects that go from 0.0.0.0 to 4.3.1.0 would need to be redone, and so on.

Second, I don't see any evidence among modern languages that non-date version numbers are off-putting to anyone. The newest C# version is C# 7, not C# 2017, but has that reduced its popularity? Java's latest update is called Java 8, not Java 2014. Likewise for Python (3.5.2), Ruby (2.4.0), Perl (5.24.0)... Plenty of major languages AREN'T doing what you suggest, and nobody (AFAIK) is complaining about those versioning schemes.

All the pros you list for this proposal are good goals to have, but I don't see any reason to think changing to a year-based numbering scheme will make any progress towards achieving those goals.

[ErikSchierboom]

I'm with @rmunn. How will using years be better than using version numbers? As far as I can tell, most languages still use version numbers. What would you do when there are two versions released in a single year? 2017.1 and 2017.2?

[Yeah69]

I don't think it is a generally bad idea, because it is more expressive than plain version numbers. In my opinion it would be better to use a year-related major number, if it was done from the beginning.
But maybe @rmunn is right about the effort.
@ErikSchierboom: JetBrains' new versioning scheme is the last two digits of the year as major version number and then a one-based incremental counter as minor and patch version number. It works well, once they switched to this scheme as a user it did not cost time to adapt at all. It kind of is obvious what the number does mean if you introduce the new versioning scheme along a current release, which uses it.

[financial-engineer]

@rmunn

I disagree that the cost would be XS. I'd rate it at an L, maybe even XL. It's not just F# version numbers that would need to change, it's the whole NuGet package ecosystem that's been built around the FSharp.Core version numbering scheme. All those binding redirects that go from 0.0.0.0 to 4.3.1.0 would need to be redone, and so on.

I'm regretful of not indicating that I think the release name and the release number should be regarded as completely separate concepts (just like these concepts are used for Visual Studio releases: it is officially named as Microsoft Visual Studio 2015, but in Help/About you can read its version number: 14.0.23107.0).

The release name (e.g., F# 2017) should be used in marketing and PR materials on websites, in new books on F#, just because the year-based release name is more expressive to potential new users than plain version numbers.

The release number from 0.0.0.0 to 4.3.1.0 and so on should continue to be used in FSharp.Core version numbering, so absolutely nothing need to be redone in terms of software.

The F# language specification should specify that it defines, for example, F# 4.3.1.0, hereinafter referred to as F# 2017, and should refer to F# as F# 2017 in the rest of its text.
As to previous language releases, I suggest mentioning them in documents as follows: F# 2005 (1.x), F# 2010 (2.0), F# 2012 (3.0), F# 2013 (3.1), F# 2015 (4.0).

Right now, the F# language specification text (and new materials promoting F# on the Microsoft website) should be changed only. So, the cost of this change would be XS.

I don't see any evidence among modern languages that non-date version numbers are off-putting to anyone. The newest C# version is C# 7, not C# 2017, but has that reduced its popularity? Java's latest update is called Java 8, not Java 2014. Likewise for Python (3.5.2), Ruby (2.4.0), Perl (5.24.0)... Plenty of major languages AREN'T doing what you suggest, and nobody (AFAIK) is complaining about those versioning schemes.

All languages you mentioned are major, mainstream (TIOBE TOP20) languages. They have huge user communities and their existence and last versions are more or less known to the vast, overwhelming majority of professional developers. Java is the undisputed market leader, TIOBE TOP1 language, C# is TIOBE TOP4 as of January 2017, Python (5th place in the TIOBE language popularity index), Ruby (12th in the TIOBE index), Perl (8th in the TIOBE index). They can afford the luxury of resting on their laurels and using release numbers instead of year-based release names.
Unfortunately, F# is not a TIOBE TOP20 language now, its place is 27th in the TIOBE index as of January 2017.
I want F# to be a mainstream language. F# needs to improve its visibility among potential new users, and the appealing to new users, year-based release name (F# 2017) is a useful PR move that F# desperately needs.

[dsyme]

Many thanks for the suggestion. I'm closing this issue - we will be sticking with the current naming pattern of F# 2.0, 3.0, 4.0, 4.1 etc.