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.
