Release D 2.079.0

[Sönke Ludwig]

Am 07.03.2018 um 13:57 schrieb Paolo Invernizzi:
> On Wednesday, 7 March 2018 at 10:13:29 UTC, Sönke Ludwig wrote:
> 
>> Well, for all of the recent releases we made sure that there was no 
>> breakage for new compiler versions. This release was an exception, 
>> because I didn't manage to put out the fixed release in time. The plan 
>> is to have all future releases go back to the normal mode where the 
>> new compiler version always works.
>>
>> Since std.experimental isn't involved from now on, it shouldn't even 
>> be necessary anymore to put out new vibe.d releases for new DMD 
>> versions, because DMD/Phobos already checks for regressions against 
>> vibe.d and all breaking changes should simply result in a deprecation 
>> warning.
> 
> That's fine, thanks.
> 
>> As for the versioning scheme, currently almost all new releases have 
>> some small breaking change or deprecation. If I'd use the "minor" 
>> version for that, then there would be no way to signal that a release 
>> makes broad and more disruptive changes, such as the 0.8.0 release. 
>> But all of this will change, as the remaining parts get pushed to 
>> separate repositories one-by-one, with their own version starting at 
>> 1.0.0.
> 
> I understand your reasoning, but there's value in being able to just 
> rapidly fix something with a new release, or just port some master 
> bug-fixes into a released version branch.
> 
> DMD is experiencing a very enjoyable release process of patch versions, 
> thanks to Martin and the team.
> 
> It your concern is only related to the best way to inform the users 
> about a broad and disruptive change in vibe-d, I suggest to simply use 
> the usual channels for that, change logs and announce forum.
> 
> My impression is that there's a lot of value in using patch for patch, 
> instead of using patch for development, also in a zero major, so I maybe 
> you should consider that change, or at least, investigate a little about 
> that opportunity.
> 
> /Paolo

But why wouldn't it be possible to make a quick bugfix release with the 
current scheme? It has happened in the past. Granted, if a 0.8.5-beta.1 
is already tagged, then using 0.8.5 for a quick intermediate release 
would be bad, but at that point the beta could likely also be turned 
into a full release pretty quickly.

But the point is that the development mode is currently still happening 
in a linear fashion. Starting to have (a) stable branch(es) with 
additional point releases would increase the overhead to a point where 
there wouldn't be any meaningful progress anymore, at least at this time.

Then there is the fact that 0.8.0 was developed in a parallel branch for 
quite a while. If the minor version would have been used to denote 
regular small updates, it would not have been possible to tag alpha/beta 
releases on the 0.8.x branch at all.