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