![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
---
Rust docs have some excellent verbiage quickly explaining the most important parts of Semver:
" The version field
Cargo bakes in the concept of Semantic Versioning, so make sure you follow some basic rules:
Before you reach 1.0.0, anything goes.
After 1.0.0, only make breaking changes when you increment the major version. In Rust, breaking changes include adding fields to structs or variants to enums. Don’t break the build.
After 1.0.0, don’t add any new public API (no new pub anything) in tiny versions. Always increment the minor version if you add any new pub structs, traits, fields, types, functions, methods or anything else.
Use version numbers with three numeric parts such as 1.0.0 rather than 1.0."---
i looked up C++ Concepts again (they are like typeclasses) and was struck that this proposal, which seems to have been Stroustrup's favorite for around a decade now, has still not been approved for C++17 (the nearly language revision years are 2003, '11, '14, '17, 2020; every other year is a major revision and every other year is a minor one; so '03 '14 '20 are minor, and '11 '17 are major).
I read http://honermann.net/blog/2016/03/06/why-concepts-didnt-make-cxx17/ and http://www.drdobbs.com/cpp/the-c0x-remove-concepts-decision/218600111 and my opinion is that Concepts is taking too long to be adopted. It sounds like the objections are basically that it's not perfect yet.
There used to be an argument about was seems to me to be whether concepts would be nominal or just structural ('duck typing'; if it has the right signature, it's automatically in the typeclass/interface ('concept')). Stroustrup's proposal seems to have been structural, with something called 'concept maps' that would be nominal when that was required. But that seemed to stir up discussion demanding more nominalness, which is one of the factors that stopped it from being approved for C++11. Stroustrop's opinion is that the 'accidental match' possibility with structural typing is a very minor problem [1], and that first they should focus on providing ways to state other behavioral properties in the signature. Stroustrop even says that there was a little chicken-and-egg "Don't standardize without commercial implementation"+"Major implementers do not implement without a standard".
My opinion is that it would be better to move forward, and that the ISO process is holding things back. (btw Stroustrup built the first C++ in like 6 months and it was a point of pride to him that it was a project that was immediately useful rather than a long 'language design' removed from application). However, i must admit that in the [Evolving a language in and for the real world: C++ 1991-2006 above article] and also in Evolving a language in and for the real world: C++ 1991-2006 Stroustrup himself advocates:
And he doesn't seem too unhappy with having chosen the ISO.
---
the C++ committee follows the ISO standard process.
"
How does the committee operate? The ISO Standards committee, SC22 WG21, operates under the ISO rules for such committees. Curiously enough, these rules are not standardized and change over time.
Many countries have national standards bodies with active C++ groups. These groups hold meetings, coordinate over the web, and some send representatives to the ISO meetings. Canada, France, Germany, Switzerland, UK, and USA are present at most meetings. Denmark, the Netherlands, Japan, Norway, Spain, and others are represented in person less frequently.
Much of the work goes on in-between meetings over the web and the results are recorded as numbered committee papers on the WG21 website.
The committee meets two to three times a year for a week each time. Most work at those meetings are in sub-working groups, such as "Core", "Library", "Evolution", and "Concurrency." As needed, there are also in-between meetings of ad-hoc working groups on specific urgent topics, such as "concepts" and "memory model." Voting takes place at the main meetings. First, working groups hold "straw votes" to see if an issue is ready for presentation to the committee as a whole. Then, the committee as a whole votes (one member one vote) and if something is accepted the nations vote. We take great care that we do not get into a situation where the majority present and the nations disagrees -- proceeding if that is the case would guarantee long-term controversy. Final votes on official drafts are done by mail by the national standards bodies.
The committee has formal liaison with the C standards group (SC22 WG14) and POSIX, and more or less formal contacts with several other groups.
Who is on the committee? The committee consists of a large number of people (about 250) out of whom 90+ turn up at the week-long meetings two or three times a year. In addition there are national standards groups and meetings in several countries. Most members contribute either by attending meetings, by taking part in email discussions, or by submitting papers for committee consideration. Most members have friends and colleagues who help them. From day #1, the committee has had members from many countries and at every meeting people from half a dozen to a dozen countries attend. The final votes are done by about 20 national standards bodies. Thus, the ISO C++ standardization is a fairly massive effort, not a small coherent group of people working to create a perfect language for "people just like themselves." The standard is what this group of volunteers can agree on as being the best they can produce that all can live with.
Naturally, many (but not all) of these volunteers have day jobs focused on C++: We have compiler writers, tool builders, library writers, application builders (too few of those), researchers (only a few), consultants, test-suite builders, and more. " -- http://www.stroustrup.com/C++11FAQ.html
sounds to me like (a) one-person one-vote majority vote of 250 ppl (or even 90 ppl) with various levels of involvement is not a good idea, and (b) one-country one-vote is not a good idea either (and neither is 'consensus' over either of those electorates). Imo voters should be limited to <<90 ppl, and no countries, and possibly weighted by a reputation system.
---
for Oot, obviously we have different priorities. We are going to be breaking backwards compatibility with each major release, and there will be plenty of major releases. Also, i don't believe in design by committee, unless the committee is very small (1? 2? 3? 5? 7? probably 3 is the max, but probably 1 is best). I certainly don't believe in letting nations, or having 90 people with varying levels of involvement and reputation, having the ability to essentially veto change. There's probably a role for having a broad discussion about things, but without giving all participants a binding vote. There may be a role for letting the maintainers of various implementations have more of a say, but since Oot aims to have a canonical implementation this may not be an issue.
But further, for Oot, i think in cases like C++ Concepts, it would be better to put something in there knowing it's not quite perfect, then change it in the next major release (breaking backwards compatibility), if the alternative is waiting over a decade (maybe it will be two decades, since '20 is a minor release, and Stroustrup says he was working on Concepts for years before '11). This way you get more users trying new language constructs out and thinking about how to improve them. Also, this must have been how C++ was originally built; if the language was first built in 6 months, then clearly Stroustrup didn't spend a decade trying to perfect his design first.
---
don't forbid dynamic typing in the library, just don't let such libraries get voted upon, or featured, or considered for inclusion in the canonical/popular or recommended lists or the stdlib, etc
---
hmm, i feel like semvar might be too stable for a language. Eg i'm guessing C++ is basically still close to version 1 according to SemVer?. I think it's great for those official modules which aren't versioned with the language, though. To loosen it for the language, first:
For the purpose of versioning (in)stability, we define 'breaking change' in a somewhat restricted manner:
What we would really prefer is a forth tuple in the semver version, above 'major', to denote 'really major' changes. So that we could distinguish 'this is a new major version because there are some breaking changes, even if we consider them minor' and 'this is a new major version because it is way different in some respects, and you might think of it as a new language'. Alternatives:
I think the simplest thing is just to not use semver, or rather, use an amended semver with another tuple.
should we call the new first item 'core' or, should we call it 'major' and call the others minor, micro, patch
---
ok here's what we can do:
version quints:
'Non-release version' is for use during development and must be set to 0 for any released versions. So, 'non-release version' 0 comes after all non-zero non-release versions.
'Major version' does not have an objective meaning, but rather is incremented when the developers feel that major changes have been made. You might say that 'a system with a different Major version is not just a new version, but essentially a new system, intended to the be the successor of the old one', or you might say that 'Major version' is a 'marketing version'. When version numbers must be squished into a semver system, the recommended squishing is: semver_major_version = major_version*256*minor_version.
Minor, Micro, Patch are like semver Major, Minor, Micro, except that when either 'Major version' OR 'minor version' is 0, all bets are off, and also that the precedence rules are modified in the obvious way to accomodate four items instead of 3.
We define 'breaking change' restrictively for things versioned with the language (but NOT for other officially approved modules; these define breakage more expansively); merely causing user code to break does not mean we will necessarily increment the major version:
---
actually let's just combine 'minor' and 'micro'.
