[Dlang-internal] dmd semver experiment

[Martin Nowak]

On Thursday, 2 November 2017 at 01:31:15 UTC, Mathias Lang wrote:
> On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak 
> wrote:
>> I'd like to push a bit on the semver discussion 
>> (https://gist.github.com/mdparker/ab61a1309752905cf93acb2653c50beb#gistcomment-2231011), partly to fix the lack of versions in the dmd dub package (http://code.dlang.org/packages/dmd).
>> [...]
>>
>> Of course the hard part of a semver transition is the 
>> semantics.
>>
>> Plase reread http://semver.org/, with the above release 
>> schedule, this would mean API changes such as deprecations, 
>> errors, symbol removals, and ABI changes could only be 
>> released every 6 months (exluding std.experimental I'd guess).
>>
>> For this to become feasible we could reuse the master/stable 
>> branches, with master being the next 6 month release version, 
>> and stable the next minor release.
>> Fixes (that don't break code) would go into stable as is the 
>> case today.
>>
>> If someone is interesting in backporting patches from stable 
>> for new patch releases, that could happen on optional 8.0/9.1 
>> branches.
>>
>> Arguments? Opinions?
>
> I think the discussion you linked, as well as this post, is 
> sadly getting lost in the bikeshedding of what number to use, 
> and missing the point on how SemVer applies to D.
>
> I have a few questions, partly rhetorical:

> 1) What does SemVer means for the compiler ? Does it apply only 
> to the *language* (I assume that's a given, that a minor 
> version will not break code but only add features) or also to 
> the interface exposed (the dub package) ? If so, what is 
> included, just the current subpackages ?

Indeed, compiler-as-library implies that the API for released 
parts is stable between major releases as well.

> 2) Do we have any plan to support multiple major versions at 
> the same time (be it now or in the far future) ? Do we have 
> plans to support minor release for a certain time / a certain 
> number of releases (e.g. bugfix would go to v80.1.x and 
> v80.2.x) ? I assume the answer is no ATM, but it's an important 
> part of SemVer and we'll eventually evolve in this direction.

See OP

> If someone is interesting in backporting patches from stable 
> for new patch releases, that could happen on optional 8.0/9.1 
> branches.

We'd need additional maintainers for this IMO.

> 3) Besides the new tags, will there be any effect on the git 
> repository ? Will master be turned into v7.x.x for example ? If 
> we go for, say 12 months support of a major, how will we deal 
> with breaking changes which are ready just after the support 
> start ? Should they linger there, or will we direct people to 
> target `v8.x.x` (or whatever the next major is) or a 
> `development` branch ? Who will handle merges and when ? How do 
> we educate on the proper usage of SemVer when stable/master is 
> already confusing to some ?

See OP

> For this to become feasible we could reuse the master/stable 
> branches, with master being the next 6 month release version, 
> and stable the next minor release.
> Fixes (that don't break code) would go into stable as is the 
> case today.

> 4) If we take a library perspective (Phobos), what qualifies as 
> breaking change ? One of the most successful project with 
> strong compatibility guarantee out there, Qt, has been using 
> some C++ tricks. There is an amazing wiki 
> (https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B) on how it's done, and the "Do and don't" is extremely useful. However in D there is no such thing. In fact, since one can test for the absence of a symbol / signature, any symbol addition can be considered a breaking change given a strict-enough policy. So what are our dos and don't?

As usual such things should be based more on recommendations and 
common sense than strict policies. Some education on binary 
compat and an example list would indeed be useful tools to guide 
decisions. As this is just a proposal such guidelines do not yet 
exist.
Also note that our community already has an established notion of 
what a breaking change is, though the understanding varies 
somewhat.

My understanding is roughly source and binary compatibility for 
any documented API usage.
Also deprecations should only happen with major releases.
As D has a very rich introspection capabilities, I doubt those 
can be fully covered.

> Last but not least, there is very little overlap between our 
> people which are knowledgeable (enough) about SemVer, and those 
> who are knowledgeable (enough) about DMD.

There isn't much to know about SemVer, other than that API/ABIs 
should not break between major releases.