Am 22.10.2020 um 17:50 schrieb Sönke Ludwig:
with the drawback that there is no supported means to still provide
something like a distinction between breaking (x) and non-breaking (y)
changes.
* with supported I mean that you can use `~>0.x.y` to restrict to a
certain x, which would be less
Am 22.10.2020 um 10:59 schrieb Robert burner Schadek:
On Wednesday, 21 October 2020 at 17:55:00 UTC, Sönke Ludwig wrote:
0.x.y vs. 1+.x.y is about the development process/state. Quite often a
design is not yet fully fleshed out in the beginning and there are
many incremental changes to the
On Tuesday, 20 October 2020 at 21:58:16 UTC, Johan Engelen wrote:
On Tuesday, 20 October 2020 at 20:21:56 UTC, aberba wrote:
On Tuesday, 20 October 2020 at 17:36:11 UTC, kinke wrote:
On Tuesday, 20 October 2020 at 16:08:47 UTC, aberba wrote:
It's an option but doesn't fill the need for an
On Thursday, 22 October 2020 at 08:59:18 UTC, Robert burner
Schadek wrote:
I should stop ranting now.
Not at all, I love it. Nice project.
On Wednesday, 21 October 2020 at 17:58:53 UTC, Sönke Ludwig wrote:
The thing is just that I don't think it is possible to find a
set of rules that always work. There will always be something
that should "obviously" be flagged as a breaking change and
something that is extremely annoying to be
On Wednesday, 21 October 2020 at 17:55:00 UTC, Sönke Ludwig wrote:
0.x.y vs. 1+.x.y is about the development process/state. Quite
often a design is not yet fully fleshed out in the beginning
and there are many incremental changes to the API. If 0.x.y
didn't exist, that would simply mean that
