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 2018
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 2018
prev sibling next 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 2018
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 2018
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 2018
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 2018
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 2018
parent reply 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 2018
parent Martin Nowak <code dawg.eu> writes:
On Sunday, 14 January 2018 at 19:11:33 UTC, Sebastian Wilzbach 
wrote:
 How would that work in terms of development?
 Would we need another branch for deprecations and breaking 
 changes?
No, master would only get merged into stable every 6 month or so. It means that more development focus would shift towards stable though.
Jan 27 2018
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
 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
Would make sense to release previews of the upcoming major release, maybe every other month to stick with todays pace.
Mar 08 2018
next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Thursday, 8 March 2018 at 18:25:44 UTC, Martin Nowak wrote:
 On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak 
 wrote:
 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
Would make sense to release previews of the upcoming major release, maybe every other month to stick with todays pace.
These versions make no sense at all as they have no meaning. Why making the change in the major version after 6 months? The API changes during that time may be minimal... After seeing this I would propose you start doing similar what Java guys decided to do starting with the Java 18.3 (also called Java 10) - to use <year>.<month>.<release> where release is that month's release that increments from 0 up...
Apr 06 2018
parent Adam Wilson <flyboynw gmail.com> writes:
On 4/6/18 02:49, Dejan Lekic wrote:
 On Thursday, 8 March 2018 at 18:25:44 UTC, Martin Nowak wrote:
 On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
 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
Would make sense to release previews of the upcoming major release, maybe every other month to stick with todays pace.
These versions make no sense at all as they have no meaning. Why making the change in the major version after 6 months? The API changes during that time may be minimal... After seeing this I would propose you start doing similar what Java guys decided to do starting with the Java 18.3 (also called Java 10) - to use <year>.<month>.<release> where release is that month's release that increments from 0 up...
I completely agree with this. I use some variation of year.month.x(.y) for all my projects. The point in time is non-arbitrary information and encoding it will make identifying builds that are compatible with given modules simpler: 18.x, 18.6, etc. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Apr 06 2018
prev sibling parent reply Johan Engelen <j j.nl> writes:
On Thursday, 8 March 2018 at 18:25:44 UTC, Martin Nowak wrote:
 On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak 
 wrote:
 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
Would make sense to release previews of the upcoming major release, maybe every other month to stick with todays pace.
Hi Martin and others, I meant to discuss the current release pace at DConf, but unfortunately I didn't, so writing here instead. I feel that the current release pace of DMD is (way) too frequent. I am referring to the pace of compiler and language changes, as opposed to releases with only bug fixes. Currently, there is no separation of the two. Because DMD's releases are not tested well [1], this results in there not being high quality releases of DMD: each new release is a combination of improved quality (bug fixes) and reduced quality (new features / language changes / regressions). From my personal experience, this leads to there not being a good version to upgrade to. Whichever version is chosen, it always comes with improvements _and_ regressions. As an unfortunate side-effect of DMD's release pace, LDC has also been releasing at breakneck speed, in order to provide an LDC version for every major dlang version (e.g 2.077, 2.078, ...). Traditionally LDC releases are based on patched DMD releases (e.g. 2.079.1), sometimes including backporting some fixes from more recent frontend versions. The patched DMD releases are more tested (and fixed) and they thus better meet the higher quality standard that is desirable for LDC as an optimizing production compiler. However, with the current pace, there is simply no time for any real testing any more. Nor is there time to incorporate (most) fixes to issues found on released versions in patched versions, because by the time issues are found and fixed there is already a new major version out (backporting does happen, but, understandably, not sufficiently). To illustrate the problem, I can share the experience of upgrading to newer compilers at Weka. I have yet to experience a compiler upgrade without compilation breakage and without linking breakage, and there have been very serious execution breakage issues too [2]. Fixing the code (e.g. accepts-invalid bugs, deprecations), adding workarounds (regressions, language changes), tracking down compiler or Phobos or code bugs, etc., all take quite some time meaning that actually _testing_ the new compiler only starts after several weeks. This is an optimistic estimate; currently Weka is at dlang 2.076 (LDC 1.6.0) and we now start real testing of dlang 2.078 (LDC 1.8.0, released over 2 months ago). As you can see, Weka is skipping versions, mainly because of the time it takes to upgrade the compiler is longer than the period between compiler releases. Recent events [2] made people at Weka and me much more wary of compiler updates, and perhaps the testing phase will also take longer than before. I feel currently the project is racing at too high speed pumping out releases, at the cost of quality and carefulness that I feel is appropriate for compiler/language development (adding to existing quality-of-implementation problems). Thus I am very much in favor of major releases every half year (or longer), with only minor releases in-between that do not add new features or language changes. Thanks for your consideration. Kind regards, Johan [1] the CI testsuites are not at all exhaustive (frequently frustrating LDC development), and I am not aware of large industrial projects participating in testing DMD releases. [2] struct layout differences between LDC 1.2.0 and 1.6.0 were causing very severe issues, and we actually put in effort trying to revert to LDC 1.2.0 again! Luckily, the revert didn't happen and Weka is still on 1.6.0.
May 13 2018
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/13/2018 12:27 PM, Johan Engelen wrote:
 I feel currently the project is racing at too high speed pumping out releases, 
 at the cost of quality and carefulness that I feel is appropriate for 
 compiler/language development (adding to existing quality-of-implementation 
 problems).
 Thus I am very much in favor of major releases every half year (or longer),
with 
 only minor releases in-between that do not add new features or language
changes.
There's always a tension between people needing things now and being conservative. Additionally, a lot of regressions have come from bug fixes. The best I can do is if you post a list of the bugzilla regressions most irksome to you, we can prioritize them.
May 15 2018
parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 15 May 2018 at 15:17:04 UTC, Walter Bright wrote:
 On 5/13/2018 12:27 PM, Johan Engelen wrote:
 I feel currently the project is racing at too high speed 
 pumping out releases, at the cost of quality and carefulness 
 that I feel is appropriate for compiler/language development 
 (adding to existing quality-of-implementation problems).
 Thus I am very much in favor of major releases every half year 
 (or longer), with only minor releases in-between that do not 
 add new features or language changes.
There's always a tension between people needing things now and being conservative.
I think the "need" of people is exaggerated, and I feel is often argued from purely ones own point of view. Shouldn't a professional language lean towards "conservative"? (if "longer than 2 month between major releases" can be called "conservative" for a programming language...)
 The best I can do is if you post a list of the bugzilla 
 regressions most irksome to you, we can prioritize them.
Thanks but my point was: that's no use. All those bugs are discovered after release, and by the time they are fixed there are 2+ new versions out with their own new set of bugs and regressions. Most often workarounds have to be added for the bugs, only in a few cases is it practical/in-time to fix the compiler (feasible because Weka already has its own fork of LDC [1]). The 'best' that can be done from my perspective is: do a major release every 6 months. What's the rush? What good have the fast cycles brought? Let's provide time for second thought, contemplating, restraint, and other things that surely would help a mature programming language. Please, currently the taste that sticks is that D is just a small group's hobby language... - Johan [1] Because a "fix" is needed that introduces a bug elsewhere, so can't upstream yet. The _minimized_ testcase is 100kbyte full of templates. We are still figuring out how to correctly fix things.
May 15 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/15/2018 11:51 AM, Johan Engelen wrote:
 I think the "need" of people is exaggerated, and I feel is often argued from 
 purely ones own point of view.
 Shouldn't a professional language lean towards "conservative"?
We've worked hard to provide fixes and enhancements to support Weka, Remedy, Sociomantic, and others who tell me they need this stuff right away. I am not in a position to tell them what they need, although I am guilty of that from time to time :-) We've had slower release cycles in the past, and those were just as strongly condemned for being slow. Hence the fundamental tension between those positions. One option is to more actively participate in the Beta release programs, to identify critical regressions before release. A good thing is that the D test suite gets added to from every regression, so they won't happen again.
May 15 2018
parent Kagamin <spam here.lot> writes:
On Tuesday, 15 May 2018 at 19:41:16 UTC, Walter Bright wrote:
 We've had slower release cycles in the past, and those were 
 just as strongly condemned for being slow.
Maybe it was before nightlies? To keep buzz the frontpage can have nightly update log. I saw that current release cycle is not fast enough for people that want stuff yesterday, so they use nightlies.
May 25 2018
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2018-05-13 21:27, Johan Engelen wrote:

 Hi Martin and others,
    I meant to discuss the current release pace at DConf, but 
 unfortunately I didn't, so writing here instead.
 
 I feel that the current release pace of DMD is (way) too frequent. I am 
 referring to the pace of compiler and language changes, as opposed to 
 releases with only bug fixes. 
What about an LTS approach that was suggested in the general form [1]. Release as often as we do now and, in addition to that, support an LTS release that will only get bug fixes? The LTS can be released once or twice every year. LDC can choose to only track the LTS releases. [1] https://forum.dlang.org/post/cgqcbhudipokyumimbua forum.dlang.org -- /Jacob Carlborg
May 15 2018
parent Martin Nowak <code dawg.eu> writes:
On Tuesday, 15 May 2018 at 18:58:56 UTC, Jacob Carlborg wrote:
 What about an LTS approach that was suggested in the general 
 form [1]. Release as often as we do now and, in addition to 
 that, support an LTS release that will only get bug fixes? The 
 LTS can be released once or twice every year. LDC can choose to 
 only track the LTS releases.

 [1] 
 https://forum.dlang.org/post/cgqcbhudipokyumimbua forum.dlang.org
LTS means extra work as someone has to backport fixes to the old release. While moving more changes to minor releases, and keeping major changes for major releases every 6 months would be about the same effort.
Aug 22 2018
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Sunday, 13 May 2018 at 19:27:50 UTC, Johan Engelen wrote:
 To illustrate the problem, I can share the experience of 
 upgrading to newer compilers at Weka.
 I have yet to experience a compiler upgrade without compilation 
 breakage and without linking breakage, and there have been very 
 serious execution breakage issues too [2]. Fixing the code 
 (e.g. accepts-invalid bugs, deprecations), adding workarounds 
 (regressions, language changes), tracking down compiler or 
 Phobos or code bugs, etc., all take quite some time meaning 
 that actually _testing_ the new compiler only starts after 
 several weeks. This is an optimistic estimate; currently Weka 
 is at dlang 2.076 (LDC 1.6.0) and we now start real testing of 
 dlang 2.078 (LDC 1.8.0, released over 2 months ago). As you can 
 see, Weka is skipping versions, mainly because of the time it 
 takes to upgrade the compiler is longer than the period between 
 compiler releases.
 Recent events [2] made people at Weka and me much more wary of 
 compiler updates, and perhaps the testing phase will also take 
 longer than before.


 I feel currently the project is racing at too high speed 
 pumping out releases, at the cost of quality and carefulness 
 that I feel is appropriate for compiler/language development 
 (adding to existing quality-of-implementation problems).
 Thus I am very much in favor of major releases every half year 
 (or longer), with only minor releases in-between that do not 
 add new features or language changes.
Just saw this discussion today, glad to finally get some feedback on this. You should also consider that a slower release cycle means bigger releases with more issues and regresssions. We've done that in the past and from my point upgrading releases was a lot worse back then, having to deal with 10 issues instead of 1 or 2. Still I agree with you that 6 breaking releases per year is too much. The proposed half-yearly major releases with bi-monthly minor releases scheme should make releases more predictable, without changing the current release scheme too much. For this to work well, we should prolly open up stable for small, strictly backwards compatible additions like new C bindings in druntime, enum additions, maybe even tiny new phobos functions. What's important is API/ABI-compatibility and to not break code in minor releases. -Martin
Aug 22 2018