www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.internals - dmd semver experiment

reply Martin Nowak <code dawg.eu> writes:
I'd like to push a bit on the semver discussion 
(https://gist.github.com/mdparker/ab61a1309752905cf93acb2653c50beb#g
stcomment-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?
Nov 01 2017
next sibling parent HaraldZealot <harald_zealot tut.by> writes:
On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
 Arguments? Opinions?
+1
Nov 01 2017
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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#g
stcomment-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.
Nov 01 2017
parent reply Leandro Lucarella <leandro.lucarella sociomantic.com> writes:
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#g
stcomment-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?
Nov 02 2017
parent reply Dicebot <z z.z> writes:
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.
Nov 03 2017
parent Martin Nowak <code dawg.eu> writes:
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.
Nov 18 2017
prev sibling next sibling parent reply Mathias Lang <mathias.lang sociomantic.com> writes:
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#g
stcomment-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.
Nov 01 2017
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Nov 03 2017
prev sibling parent Martin Nowak <code dawg.eu> writes:
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#g
stcomment-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.
Nov 18 2017
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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#g
stcomment-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
Nov 03 2017
parent Martin Nowak <code dawg.eu> writes:
On Friday, 3 November 2017 at 07:43:25 UTC, Jacob Carlborg wrote:
 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.
Good point, we haven't thought about compiler-as-a-library stability yet.
Jan 02
prev sibling next sibling parent meppl <mephisto nordhoff-online.de> writes:
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
Nov 03 2017
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
 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 does not make sense as we all know that major version is 2 so why not tag it appropriately with v2.76.0 or v2.7.6-0 or something similar? Why duplicating data in these tags?
Dec 12 2017
parent reply user1234 <user1234 12.nl> writes:
On Tuesday, 12 December 2017 at 16:50:36 UTC, Dejan Lekic wrote:
 On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak 
 wrote:
 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 does not make sense as we all know that major version is 2 so why not tag it appropriately with v2.76.0
Yes, i don't see why this wouldn't go this way. If you continue developing the language as you do since years, this scheme works fine, despite of the "2" that's not really useful.
 or v2.7.6-0
For this to work they'd have to change the way they develop. Also where /when to start with the new scheme not very clear. The first proposition works well because there's a minor release every 3 months, between patches and the optional component can be used to tag betas and release candidates. Maybe i'm blind or stupid but <language version>.<minor release every 3 months>.<unplanned patches> etc would work fine.
Dec 26 2017
parent Martin Nowak <code dawg.eu> writes:
On Wednesday, 27 December 2017 at 05:59:28 UTC, user1234 wrote:
 On Tuesday, 12 December 2017 at 16:50:36 UTC, Dejan Lekic wrote:
 On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak 
 wrote:
 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 does not make sense as we all know that major version is 2 so why not tag it appropriately with v2.76.0
No, there have been 76 major versions of D2. https://dlang.org/changelog/index.html
 <language version>.<minor release every 3 months>.<unplanned 
 patches>

 etc would work fine.
See http://forum.dlang.org/post/mcatldmxmtfwfcljzevs forum.dlang.org, we're not guaranteeing API/ABI stability between releases atm., so practically we're doing a major release every two month. Using 2 as major version meant no more API/ABI changes until 3.x.y.
Jan 02
prev sibling parent reply Dragos Carp <dragoscarp gmail.com> writes:
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#g
stcomment-2231011), partly to fix the lack of versions in the dmd dub package
(http://code.dlang.org/packages/dmd).


 Arguments? Opinions?
Related to that, there is a library that I wrote two years ago: http://code.dlang.org/packages/semver. Maybe you find it useful.
Dec 13 2017
parent reply Elronnd <elronnd elronnd.net> writes:
Having '2' as part of the semver version isn't really useful 
because if there's a d3, it'll be a completely different program, 
not a new version.  D2 will be completely and wholly separate 
from D3.  Why not, e.g., make the version 77.0.0?
Dec 23 2017
parent reply Martin Nowak <code dawg.eu> writes:
On Sunday, 24 December 2017 at 04:47:30 UTC, Elronnd wrote:
 D2 will be completely and wholly separate from D3.  Why not, 
 e.g., make the version 77.0.0?
See https://gist.github.com/mdparker/ab61a1309752905cf93acb2653c50beb#description
 An argument can be made that jumping from a major version of 2 
 to 75 is jarring, while starting with 3.0.0 is more natural.
Furthermore we should reduce the interval of major releases from currently 2 month, to 6 or 12 months, and sticking with the 07x numbers isn't too helpful for that.
Jan 02
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 2 January 2018 at 12:23:16 UTC, Martin Nowak wrote:
 Furthermore we should reduce the interval of major releases 
 from currently 2 month, to 6 or 12 months, and sticking with 
 the 07x numbers isn't too helpful for that.
The greatest strength of the current development model is the fast release schedule. We should strive to keep it at all costs! If that's the cost of having semantic versioning we definitely better off without it.
Jan 02
parent reply Martin Nowak <code dawg.eu> writes:
On Tuesday, 2 January 2018 at 12:55:11 UTC, Petar Kirov 
[ZombineDev] wrote:
 The greatest strength of the current development model is the 
 fast release schedule. We should strive to keep it at all 
 costs! If that's the cost of having semantic versioning we 
 definitely better off without it.
We would still keep the bi-monthly releases, but make them point releases. So new additions could still be released regularly, but breaking changes and deprecations would have to wait until the next major release.
Jan 02
parent reply Dicebot <a a.a> writes:
On Wednesday, 3 January 2018 at 04:50:51 UTC, Martin Nowak wrote:
 We would still keep the bi-monthly releases, but make them 
 point releases.
 So new additions could still be released regularly, but 
 breaking changes and deprecations would have to wait until the 
 next major release.
You probably mean minor releases. Point ones can only contain bug fixes and no features.
Jan 07
parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 8 January 2018 at 06:21:05 UTC, Dicebot wrote:
 On Wednesday, 3 January 2018 at 04:50:51 UTC, Martin Nowak 
 wrote:
 We would still keep the bi-monthly releases, but make them 
 point releases.
 So new additions could still be released regularly, but 
 breaking changes and deprecations would have to wait until the 
 next major release.
You probably mean minor releases. Point ones can only contain bug fixes and no features.
Yes, semver uses the less confusion terms MINOR (bi-monthly) and PATCH (bugfixes).
Jan 14
parent Sebastian Wilzbach <seb wilzba.ch> writes:
On 2018-01-14 20:04, Martin Nowak via Dlang-internal wrote:
 On Monday, 8 January 2018 at 06:21:05 UTC, Dicebot wrote:
 On Wednesday, 3 January 2018 at 04:50:51 UTC, Martin Nowak wrote:
 We would still keep the bi-monthly releases, but make them point 
 releases.
 So new additions could still be released regularly, but breaking 
 changes and deprecations would have to wait until the next major 
 release.
You probably mean minor releases. Point ones can only contain bug fixes and no features.
Yes, semver uses the less confusion terms MINOR (bi-monthly) and PATCH (bugfixes).
How would that work in terms of development? Would we need another branch for deprecations and breaking changes?
Jan 14