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.


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.

Reply via email to