Released vibe.d 0.8.2

[Sönke Ludwig]

Am 17.12.2017 um 16:24 schrieb bauss:
> On Sunday, 17 December 2017 at 14:13:05 UTC, WebFreak001 wrote:
>> On Sunday, 17 December 2017 at 12:52:57 UTC, bauss wrote:
>>> This shouldn't have been released as 0.8.2, because it has a lot of 
>>> breaking changes.
>>>
>>> For an instance anything that relies on HTTPServerRequest.path will 
>>> break.
>>>
>>> I'm aware that there has been added the "requestPath" property, but 
>>> it's still a breaking change to all existing code that relies on the 
>>> old "path" property. Especially when it's used to manipulate the path 
>>> you receive.
>>>
>>> Diamond cannot currently be used with latest release of vibe.d, 
>>> because of this and it was relying on vibe.d with following dependency:
>>>
>>> "vibe-d": "~>0.8.1"
>>>
>>> 0.8.2 should not be a breaking change, assuming you follow semantic 
>>> versioning.
>>>
>>> https://semver.org/
>>
>> 4. Major version zero (0.y.z) is for initial development. Anything may 
>> change at any time. The public API should not be considered stable.
> 
> 0.x.Y should always be compatible with 0.x.Z without breaking changes.
> 
> Since it's MAJOR.MINOR.PATCH
> 
> This is a patch release 0.8.1 to 0.8.2 which means:
> 
> "PATCH version when you make backwards-compatible bug fixes."
> 
> Even a minor version should be backward-compatible.
> 
> "MINOR version when you add functionality in a backwards-compatible 
> manner, and"
> 
> I'm all for deprecating said features, but plain removing them in a 
> release like this is a breaking change and should at the very least be a 
> minor version upgrade, but definitely not a patch.

The above was actually a quote from the spec, so there is no doubt that 
any 0.x.y release may contain breaking changes. But apart from that, the 
development has always gone this way so far. I just made 0.8.0 a new 
"minor" version, because it is in many ways a much larger step than the 
previous releases and not all breaking changes could reasonably follow 
the usual deprecation paths.

However, as individual sub packages are separated out into their own 
repositories (such as diet-ng and vibe-core), their versioning will 
start as 1.0.0 and will follow the usual versioning rules for >= 1.x.y 
releases.

But what do you mean with anything will break using `.path`? It follows 
the usual deprecation path - currently it's just documented as 
deprecated. In one or two releases, the `deprecated` attribute will be 
set and a few releases later it will finally be removed. By that time 
projects will have had quite some time to react on the deprecation.