Jump to page: 1 2
Thread overview
dmd semver experiment
Nov 03
Dicebot
3 days ago
Martin Nowak
3 days ago
Martin Nowak
Nov 03
meppl
November 01
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).

I think with the 2.076.1 -> D2-7.6.1, 2.077.0 -> D2-7.7.0, 2.080.0 -> D2-8.0.0 mapping we have quite a good candidate to swap over while keeping some connection to the old versioning.

A possible release schedule for this would be a major release every 6 (or 12 months), and minor releases in between.

v8.0.0 - Jan 1 2018
v8.0.x - unscheduled patch releases
v8.1.0 - Mar 1 2018
v8.1.x - unscheduled patch releases
v8.2.0 - May 1 2018
v8.2.x - unscheduled patch releases
v9.0.0 - Jul 1 2018
v9.0.x - unscheduled patch releases
v9.1.0 - Sep 1 2018
v9.1.x - unscheduled patch releases
v9.2.0 - Nov 1 2018
v9.2.x - unscheduled patch releases
v10.0.0 - Jan 1 2019
v10.0.x - unscheduled patch releases
...

I'd like to go ahead, even though it doesn't yet match the semantics part of semver, to add some tags to dmd.

v7.6.0+2.076.0
v7.6.0-b1+2.076.0-b1
v7.6.0-b2+2.076.0-b2
v7.6.0-rc1+2.076.0-rc1
v7.6.1+2.076.1
v7.6.1-b1+2.076.1-b1
v7.7.0-beta.1+2.077.0-beta.1
v7.7.0-beta.2+2.077.0-beta.2
v7.7.0-rc.1+2.077.0-rc.1

This allows using of the versioned dmd dub package, but it might also help us to fix/test build scripts before doing any real transition.

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?
November 01
On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
>
> Arguments? Opinions?

+1


November 01
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).
>
> [...]

I'm really not a fan of making up numbers like that and starting from an arbitrary number. If anything, we'll have people asking questions all the time about "wtf happened between v1.x and v7.x..?". It's going to be come a meme..

Why not make 2.076.1 => v0.76.1, 2.077.0 => v0.77.0, etc?

And then you can start with v1.0 as the very first semver release.
November 02
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 ?

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.

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 ?

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 ?

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. And that overlap is, AFAIK, only you.
November 02
On Wednesday, 1 November 2017 at 23:58:07 UTC, Andrej Mitrovic 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).
>>
>> [...]
>
> I'm really not a fan of making up numbers like that and starting from an arbitrary number. If anything, we'll have people asking questions all the time about "wtf happened between v1.x and v7.x..?". It's going to be come a meme..
>
> Why not make 2.076.1 => v0.76.1, 2.077.0 => v0.77.0, etc?
>
> And then you can start with v1.0 as the very first semver release.

Since there was a v1.0 already released, I think this would be very confusing.

I think the best way to start is just to use 2.77.0, that's actually what is closest to semver in any case and works with the current scheme too.

@Martin, why go with 7.7.0 instead of 2.77.0?
November 03
On 2017-11-02 02:31, Mathias Lang wrote:

> 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) ? 

I would say that the CLI is the interface as well. I'm thinking that the Dub package is almost a separate product.

> If so, what is included, just the current subpackages ?

I would assume everything that is included in the Dub package. Currently the main package is empty and only acts as super package or wrapper around the sub packages.

-- 
/Jacob Carlborg
November 03
On 2017-11-01 11:48, 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).

Would that mean that we would need to maintain a stable API for the root, lexer and parser packages? Which I assume we currently don't.

-- 
/Jacob Carlborg
November 03
On Thursday, 2 November 2017 at 15:38:10 UTC, Leandro Lucarella wrote:
> I think the best way to start is just to use 2.77.0, that's actually what is closest to semver in any case and works with the current scheme too.

I don't think this is possible as DMD releases are normally major by SemVer criteria.

And making version look like SemVer without actually ensuring stability guarantees it promises is hardly a good idea.
November 03
On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
>
> I think with the 2.076.1 -> D2-7.6.1, 2.077.0 -> D2-7.7.0, 2.080.0 -> D2-8.0.0 mapping we have quite a good candidate to swap over while keeping some connection to the old versioning.
>
> A possible release schedule for this would be a major release every 6 (or 12 months), and minor releases in between.
>
> v8.0.0 - Jan 1 2018
> v8.0.x - unscheduled patch releases
> v8.1.0 - Mar 1 2018
> v8.1.x - unscheduled patch releases
> v8.2.0 - May 1 2018
> v8.2.x - unscheduled patch releases
> v9.0.0 - Jul 1 2018
> v9.0.x - unscheduled patch releases
> v9.1.0 - Sep 1 2018
> v9.1.x - unscheduled patch releases
> v9.2.0 - Nov 1 2018
> v9.2.x - unscheduled patch releases
> v10.0.0 - Jan 1 2019
> v10.0.x - unscheduled patch releases
> ...


in other words, in the future you would omit version numbers?

for example:
after  dmd_v2.78.0  a major change is planed. then the consequence would be to omit v2.79.0, but directly jump to v2.80.0
3 days ago
On Friday, 3 November 2017 at 09:47:37 UTC, Dicebot wrote:
> I don't think this is possible as DMD releases are normally major by SemVer criteria.
>
> And making version look like SemVer without actually ensuring stability guarantees it promises is hardly a good idea.

Yes, that's why 2.77.0 isn't a useful approach. Changing the version schema without doing the semantic part is pointless.
« First   ‹ Prev
1 2