RejectedSoftware Forums

On Thu, 18 Feb 2016 23:00:25 GMT, David Monagle wrote:

Hi all,

I'd like to bring up, what I believe, to be a fairly significant issue with the version numbering of vibe. This is an issue that seems to have hit the open source community en masse. Semantic versioning is usually along the lines of:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

But in the effort to avoid a 1.0 (just look at the number of dub packages that sit below 1) people start using the minor for major and the patch for minor.

So what? Well I'll give you an example of where this would have been handy. Vibe.d 0.7.26 introduced a bug where we could not make any https connections via httpRequest due to a certificate error. At the same time it fixed other issues that we had been waiting on. So, as has been practice for us for 15 months and counting, we need to have a submoduled version of vibe.d, with cherry picked changes made. The case I put forward is:

The version of vibe.d should have been 0.8.0
The fix for this error should have been cherry picked to the 0.8.0 branch and tagged 0.8.1 therefore allowing people using vibe.d to select the fixed version and move on. This would then vindicate the use of ~>0.8.0 in our dub.son(sdl)

I'm sorry if this comes across as ranty, but we've had a few major issues with the packaging system of late which has cost far more time than I would like. Having to maintain submodules just to keep a stable version of vibe running with the latest bug fixes is getting very difficult.

TLDR

Can we put bug fixes into the patch version of vibe.d with the view to release as the urgency of the bug dictates and move refactors and features into the minor versions. Then all look forward to 1.0.

Cheers,

David.

I second this for the exact same reason I also didn't upgrade 0.7.26 despite it having some fixes important fixes for us. It would be great to have small point releases in between major patches.

We use dub as our package manager in all the build infrastructure, so for us to use my own vibe.d fork would mean I'd have to submit it to code.dlang.org, or I'd have to clone my fork and add-local on every machine that builds code. Both of these feel like major pain in the rectum to maintain.

Perhaps, what would work for this sort of multi-developer/builder environments could be a way for dub to support private repositories. e.g. It could check my company's private repository and only a package was not found there it would check the official repository. Sort of like adding ppa's to aptitude in Ubuntu.
This way all I'd have to do would be to set an environment variable or pass an argument to dub or have some sort of /etc/dub.conf and everything thing else would be handled transparently.

Would also make it easier for me to test my vibe.d contributions in our live infrastructure before submitting a PR.

Would this also make it more convenient for you to work with own forks, David?

Am 19.02.2016 um 00:00 schrieb David Monagle:

Hi all,

I'd like to bring up, what I believe, to be a fairly significant issue with the version numbering of vibe. This is an issue that seems to have hit the open source community en masse. Semantic versioning is usually along the lines of:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

But in the effort to avoid a 1.0 (just look at the number of dub packages that sit below 1) people start using the minor for major and the patch for minor.

So what? Well I'll give you an example of where this would have been handy. Vibe.d 0.7.26 introduced a bug where we could not make any https connections via httpRequest due to a certificate error. At the same time it fixed other issues that we had been waiting on. So, as has been practice for us for 15 months and counting, we need to have a submoduled version of vibe.d, with cherry picked changes made. The case I put forward is:

The version of vibe.d should have been 0.8.0
The fix for this error should have been cherry picked to the 0.8.0 branch and tagged 0.8.1 therefore allowing people using vibe.d to select the fixed version and move on. This would then vindicate the use of ~>0.8.0 in our dub.son(sdl)

I'm sorry if this comes across as ranty, but we've had a few major issues with the packaging system of late which has cost far more time than I would like. Having to maintain submodules just to keep a stable version of vibe running with the latest bug fixes is getting very difficult.

TLDR

Can we put bug fixes into the patch version of vibe.d with the view to release as the urgency of the bug dictates and move refactors and features into the minor versions. Then all look forward to 1.0.

Cheers,

David.

The situation will change soon. I agree that the current version scheme
is not ideal, but it simply reflects the development model as it stands,
which is the only practical one for me currently (continually work a
single branch with bugfixes, new features and deprecations). But the
plan is to separate parts of the library into separate repositories and
then start using >=1.0.0 versions for the individual parts soon
afterwards. Since the low-level modules will have an API that is mostly
stable, it then makes sense to maintain stable branches for those.

The process will happen step-by-step, where the old monolithic
repository continues to live alongside the new ones (as they each get
created), but the details still need to be worked out. The monolithic
repository will only receive bug fixes for those modules that are
already separated out.

While each sub package is getting separated out, it will potentially
receive larger API changes or refactorings that may not be fully
backwards compatible. The first two candidates, vibe.core and vibe.http,
in particular will get major changes (including HTTP/2 support and
RC-based resource management).

On Fri, 19 Feb 2016 11:02:28 +0100, Sönke Ludwig wrote:

Am 19.02.2016 um 00:16 schrieb Márcio Martins:

Perhaps, what would work for this sort of multi-developer/builder environments could be a way for dub to support private repositories. e.g. It could check my company's private repository and only a package was not found there it would check the official repository. Sort of like adding ppa's to aptitude in Ubuntu.
This way all I'd have to do would be to set an environment variable or pass an argument to dub or have some sort of /etc/dub.conf and everything thing else would be handled transparently.

Would also make it easier for me to test my vibe.d contributions in our live infrastructure before submitting a PR.

You can specify an own registry using the --registry=<URL> switch, or
by adding a "registryUrls": ["<url>"] field to ~/.dub/settings.json.
These will have precedence over code.dlang.org. The main problem is that
the dub-registry currently still requires the repository to be hosted on
GitHub or BitBucket. But there is also a GitLab implementation that can
be enabled manually in the source, which is what I added to support this
for our internal repositories.

But generally, the Repository interface is quite straightforward, so
adding other back ends is definitely a possibility.

This is great! Thanks!