• Imperatorn (11/11) Nov 03 2021 I don't have time to write a proper post, but I have a suggestion.
• Paul Backus (7/11) Nov 03 2021 I think your hopes here are probably misplaced. Every change to
• Imperatorn (3/14) Nov 03 2021 I'm not thinking primarily about the code itself, but rather the
• deadalnix (2/13) Nov 03 2021 Worse: they'll take longer to be be discovered and fixed.
• Imperatorn (5/21) Nov 03 2021 What's the alternative? Just rolling releases every day or even
• bachmeier (6/19) Nov 03 2021 My preference is once a year, after dconf, they release a new
• Imperatorn (7/32) Nov 03 2021 Yeah, there's no such thing as a new idea. I just wasn't around
• bachmeier (15/49) Nov 03 2021 The two main advantages from my perspective:
• Guillaume Piolat (4/5) Nov 03 2021 From 2012 to 2014 there was about 3 releases of DMD per year and
• Imperatorn (4/10) Nov 03 2021 I understand. But wouldn't that depend on the quality of the
• Guillaume Piolat (3/5) Nov 03 2021 I guess so. At the times it didn't felt right and people, guess
• Imperatorn (3/9) Nov 04 2021 What a surprise 😅
• Dukc (8/21) Nov 04 2021 If we are to do this, I think a better model would be to have
• Imperatorn (4/13) Nov 04 2021 Yes, I know, I was just referring to what they are called by us

Imperatorn <johan_forsberg_86 hotmail.com> writes:

I don't have time to write a proper post, but I have a suggestion.

Could we increase the time between releases?

Today we have in practice 15 days between minor versions. That 
might be ok, but "major" releases are too frequent.

The logic behind that is it would hopefully put more focus on 
testing and reliability etc. If we have to live with a release 
for a longer time period, the theory is everyone will be more 
cautious when making a change.

Theory vs practice applies ofc, but I think it could be positive. 
As for what amount of time makes most sense, I'm not sure yet.

Thoughts?

Paul Backus <snarwin gmail.com> writes:

On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:
 The logic behind that is it would hopefully put more focus on 
 testing and reliability etc. If we have to live with a release 
 for a longer time period, the theory is everyone will be more 
 cautious when making a change.

I think your hopes here are probably misplaced. Every change to 
D's core components (dmd, druntime, and phobos) is already run 
through the full CI suite and subject to code review before 
merging. The kinds of bugs that slip past these filters are 
probably not going to be caught by something as simple as "more 
caution."

Imperatorn <johan_forsberg_86 hotmail.com> writes:

On Wednesday, 3 November 2021 at 14:30:52 UTC, Paul Backus wrote:
 On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:
 The logic behind that is it would hopefully put more focus on 
 testing and reliability etc. If we have to live with a release 
 for a longer time period, the theory is everyone will be more 
 cautious when making a change.

 I think your hopes here are probably misplaced. Every change to 
 D's core components (dmd, druntime, and phobos) is already run 
 through the full CI suite and subject to code review before 
 merging. The kinds of bugs that slip past these filters are 
 probably not going to be caught by something as simple as "more 
 caution."

I'm not thinking primarily about the code itself, but rather the 
overall structure and support/maintainability.

deadalnix <deadalnix gmail.com> writes:

On Wednesday, 3 November 2021 at 14:30:52 UTC, Paul Backus wrote:
 On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:
 The logic behind that is it would hopefully put more focus on 
 testing and reliability etc. If we have to live with a release 
 for a longer time period, the theory is everyone will be more 
 cautious when making a change.

 I think your hopes here are probably misplaced. Every change to 
 D's core components (dmd, druntime, and phobos) is already run 
 through the full CI suite and subject to code review before 
 merging. The kinds of bugs that slip past these filters are 
 probably not going to be caught by something as simple as "more 
 caution."

Worse: they'll take longer to be be discovered and fixed.

Imperatorn <johan_forsberg_86 hotmail.com> writes:

On Wednesday, 3 November 2021 at 15:36:41 UTC, deadalnix wrote:
 On Wednesday, 3 November 2021 at 14:30:52 UTC, Paul Backus 
 wrote:
 On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn 
 wrote:
 The logic behind that is it would hopefully put more focus on 
 testing and reliability etc. If we have to live with a 
 release for a longer time period, the theory is everyone will 
 be more cautious when making a change.

 I think your hopes here are probably misplaced. Every change 
 to D's core components (dmd, druntime, and phobos) is already 
 run through the full CI suite and subject to code review 
 before merging. The kinds of bugs that slip past these filters 
 are probably not going to be caught by something as simple as 
 "more caution."

 Worse: they'll take longer to be be discovered and fixed.

What's the alternative? Just rolling releases every day or even 
don't have releases at all?

To me a release is something that signifies a unit of some kind, 
stuff that belongs together.

bachmeier <no spam.net> writes:

On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:
 I don't have time to write a proper post, but I have a 
 suggestion.

 Could we increase the time between releases?

 Today we have in practice 15 days between minor versions. That 
 might be ok, but "major" releases are too frequent.

 The logic behind that is it would hopefully put more focus on 
 testing and reliability etc. If we have to live with a release 
 for a longer time period, the theory is everyone will be more 
 cautious when making a change.

 Theory vs practice applies ofc, but I think it could be 
 positive. As for what amount of time makes most sense, I'm not 
 sure yet.

 Thoughts?

My preference is once a year, after dconf, they release a new 
stable version of the compiler. That wouldn't prevent them from 
having other releases in between, they just wouldn't be "stable" 
releases. I don't think this will go anywhere though. It's been 
discussed before and most people don't see a need to change it.

Imperatorn <johan_forsberg_86 hotmail.com> writes:

On Wednesday, 3 November 2021 at 15:35:51 UTC, bachmeier wrote:
 On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:
 I don't have time to write a proper post, but I have a 
 suggestion.

 Could we increase the time between releases?

 Today we have in practice 15 days between minor versions. That 
 might be ok, but "major" releases are too frequent.

 The logic behind that is it would hopefully put more focus on 
 testing and reliability etc. If we have to live with a release 
 for a longer time period, the theory is everyone will be more 
 cautious when making a change.

 Theory vs practice applies ofc, but I think it could be 
 positive. As for what amount of time makes most sense, I'm not 
 sure yet.

 Thoughts?

 My preference is once a year, after dconf, they release a new 
 stable version of the compiler. That wouldn't prevent them from 
 having other releases in between, they just wouldn't be 
 "stable" releases. I don't think this will go anywhere though. 
 It's been discussed before and most people don't see a need to 
 change it.

Yeah, there's no such thing as a new idea. I just wasn't around 
when those discussions where had 😎

I think we have pretty good tests for our code, so I'm not so 
scared there. It's more what you could maybe call "architectural 
hygiene", how you plan for changes, what to do when requirement x 
comes up, should we use strict semver etc.

bachmeier <no spam.net> writes:

On Wednesday, 3 November 2021 at 16:09:27 UTC, Imperatorn wrote:
 On Wednesday, 3 November 2021 at 15:35:51 UTC, bachmeier wrote:
 On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn 
 wrote:
 I don't have time to write a proper post, but I have a 
 suggestion.

 Could we increase the time between releases?

 Today we have in practice 15 days between minor versions. 
 That might be ok, but "major" releases are too frequent.

 The logic behind that is it would hopefully put more focus on 
 testing and reliability etc. If we have to live with a 
 release for a longer time period, the theory is everyone will 
 be more cautious when making a change.

 Theory vs practice applies ofc, but I think it could be 
 positive. As for what amount of time makes most sense, I'm 
 not sure yet.

 Thoughts?

 My preference is once a year, after dconf, they release a new 
 stable version of the compiler. That wouldn't prevent them 
 from having other releases in between, they just wouldn't be 
 "stable" releases. I don't think this will go anywhere though. 
 It's been discussed before and most people don't see a need to 
 change it.

 Yeah, there's no such thing as a new idea. I just wasn't around 
 when those discussions where had 😎

 I think we have pretty good tests for our code, so I'm not so 
 scared there. It's more what you could maybe call 
 "architectural hygiene", how you plan for changes, what to do 
 when requirement x comes up, should we use strict semver etc.

The two main advantages from my perspective:

- It's easy to follow and plan for changes if the release is once 
a year. I am not an insider, so it is difficult to keep track of 
everything. I usually learn about changes because I installed a 
new version of the compiler and I'm getting warnings or error 
messages.
- You can add a preview flag for a potential feature to the 
frequent releases but never add it to the stable release if it 
doesn't show its worth.

A good example of how this hurts from a marketing perspective: 
most non-users are unlikely to ever hear of importC. It showed up 
in a random release alongside bug fixes. If you had a single 
presentation each year showing off all the things coming in the 
next "release" you could generate some buzz.

Guillaume Piolat <first.last gmail.com> writes:

On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:
 Thoughts?

 From 2012 to 2014 there was about 3 releases of DMD per year and 
everyone cheered up when the pace of releases went faster again. 
It's not sure you would like slower releases too much.

Imperatorn <johan_forsberg_86 hotmail.com> writes:

On Wednesday, 3 November 2021 at 16:59:26 UTC, Guillaume Piolat 
wrote:
 On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:
 Thoughts?

 From 2012 to 2014 there was about 3 releases of DMD per year 
 and everyone cheered up when the pace of releases went faster 
 again. It's not sure you would like slower releases too much.

I understand. But wouldn't that depend on the quality of the 
releases?

Guillaume Piolat <first.last gmail.com> writes:

On Wednesday, 3 November 2021 at 17:18:19 UTC, Imperatorn wrote:
 I understand. But wouldn't that depend on the quality of the 
 releases?

I guess so. At the times it didn't felt right and people, guess 
what, would complain on the forums! :)

Imperatorn <johan_forsberg_86 hotmail.com> writes:

On Wednesday, 3 November 2021 at 23:44:27 UTC, Guillaume Piolat 
wrote:
 On Wednesday, 3 November 2021 at 17:18:19 UTC, Imperatorn wrote:
 I understand. But wouldn't that depend on the quality of the 
 releases?

 I guess so. At the times it didn't felt right and people, guess 
 what, would complain on the forums! :)

What a surprise 😅

Dukc <ajieskola gmail.com> writes:

On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:
 I don't have time to write a proper post, but I have a 
 suggestion.

 Could we increase the time between releases?

 Today we have in practice 15 days between minor versions. That 
 might be ok, but "major" releases are too frequent.

 The logic behind that is it would hopefully put more focus on 
 testing and reliability etc. If we have to live with a release 
 for a longer time period, the theory is everyone will be more 
 cautious when making a change.

 Theory vs practice applies ofc, but I think it could be 
 positive. As for what amount of time makes most sense, I'm not 
 sure yet.

 Thoughts?

If we are to do this, I think a better model would be to have 
every two or three minor releases (With minor releases I mean 
what you do with major releases. The correct term for what you 
call minor releases are patch releases.) be "supported" releases 
where the latest stable branch and patch releases are based on. 
Minor releases would be just as frequent as now, just that the 
non-supported minor releases would not get patches.

Imperatorn <johan_forsberg_86 hotmail.com> writes:

On Thursday, 4 November 2021 at 12:19:07 UTC, Dukc wrote:
 On Wednesday, 3 November 2021 at 09:13:59 UTC, Imperatorn wrote:
 [...]

 If we are to do this, I think a better model would be to have 
 every two or three minor releases (With minor releases I mean 
 what you do with major releases. The correct term for what you 
 call minor releases are patch releases.) be "supported" 
 releases where the latest stable branch and patch releases are 
 based on. Minor releases would be just as frequent as now, just 
 that the non-supported minor releases would not get patches.

Yes, I know, I was just referring to what they are called by us 
currently in the release-schedule list.

https://dlang.org/changelog/release-schedule.html