Release D 2.079.0

[Sönke Ludwig]

Am 07.03.2018 um 10:17 schrieb Paolo Invernizzi:
> On Wednesday, 7 March 2018 at 04:02:18 UTC, Seb wrote:
>> On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote:
>>> On 3/6/18 2:30 PM, Martin Nowak wrote:
>>>> On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote:
>>>
>>>>> But if needed, you could have your dub package depend on a prior 
>>>>> version.
>>>>
>>>> http://code.dlang.org/packages/stdx-allocator ;)
>>>>
>>>
>>> This is the answer, vibe.d should depend on stdx-allocator.
>>>
>>> -Steve
>>
>> Vibe.d (and a lot of other projects) do depend on this package, see e.g.
>>
>> https://github.com/vibe-d/vibe.d/pull/1983
>>
>> Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm 
>> and not released as the latest stable tag yet, which is the reason for 
>> Atila's justified complaint.
> 
> The point is just to persuade Sonke to do his development in the minor 
> version and increase it during every vibe-d release, and keep the patch 
> version for fast fixes of the latest released vibe-d when a new version 
> of the compiler is being released.
> 
> The actual policy is just an ask for problems...
> 
> It's not a big deal to fix the breakage on the latest released vibe-d 
> code, it's a fast process. But it's a problem in just coordinating the 
> next release of vibe-d with the release of the compiler, if you need to 
> do this, like in this case.
> 
> /Paolo
> 

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.

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.