Should 0.x.y and 0.0.z versions be treated differently?

[AlCalzone]

From https://github.com/npm/node-semver#caret-ranges-123-025-004

Allows changes that do not modify the left-most non-zero element in the [major, minor, patch] tuple. In other words, this allows patch and minor updates for versions 1.0.0 and above, patch updates for versions 0.X >=0.1.0, and no updates for versions 0.0.X.

Many authors treat a 0.x version as if the x were the major "breaking-change" indicator.

Caret ranges are ideal when an author may make breaking changes between 0.2.4 and 0.3.0 releases, which is a common practice. However, it presumes that there will not be breaking changes between 0.2.4 and 0.2.5. It allows for changes that are presumed to be additive (but non-breaking), according to commonly observed practices.

The original dependabot didn't auto-merge anything below 1.0.0. Although that could be a tad annoying, it might be worth to consider.

[ahmadnassri]

I think that can be left to the application owner to decide how they want to indicate ranges in their package.json or equivalent... dependabot already follows that.

and following the semver spec https://semver.org/ major is just a number, there is no indication that 0.x.x has any special meaning

also, as per the spec, that's what pre-release and other identifiers are for

[AlCalzone]

I was thinking in regards to auto-merging these PRs. semver.diff treats a minor update with major version 0 like any other minor update. So if the auto-merge config allows minor updates, they will be auto-merged. The "old" dependabot did not auto-merge those updates.

Just wanted to hear your thoughts if this warrants a special treatment in the action. I'm fine with both.

[ahmadnassri]

I'd leave this open for a bit and see what other users might say

[peterbe]

I prefer it this (action-dependabot-auto-merge) way. Not the old way. Far too many packages start at 0.x.y and take years to make it to 1.0.0 and that makes them hopeless for auto-merging. So my vote is to not do anything special or ad-hoc when the major number is a 0.

[narwold]

Where I work, our priority is not to auto-merge breaking changes. We have found 0.x.x 3rd-party package bumps to often include breaking changes. Even if that's not a standard, we still have to deal with it... so auto-merging these is not an option for us. Is there any way to configure this action to NOT auto-merge 0.x.x bumps?

[ahmadnassri]

@narwold if you configure the rules to only auto-merge "patch" (a.k.a 0.x.y where y is changed) then it will only auto-merge these...

you can also configure specific pacakages to behavre differently than the glocal rule, (see full config syntax):

- match:
    dependency_name: package-that-only-has-zero-version
    update_type: semver:major

other than that, I'm not sure what further control are you expecting?

[narwold]

That would necessitate adding individual rules for each and every one of our 0.x.y dependencies, which doesn't seem like a sustainable solution.

More to the point though, semver.org officially lists 0.x.y as unstable (see https://semver.org/#spec-item-4), so it doesn't make sense to auto-merge them.

[ahmadnassri]

"the decision to merge" shouldnt' be confused with "stability" of a package ...

e.g. if you're developing a series of interdependant packages, all while they are in the "pre 1.x.x" stage, you might still want to "merge" changes ...

but that could turn into a philisophical argument ....

anyway, I think your issue will be solved with #43 which intruduces the ability to declare dependencaies to ignore from the global rules and opens up the door for more flexible configuration (e.g. using regex in ignored package names) ...

[narwold]

You may want to merge something that's unstable into your codebase if you test and determine that it will not break your codebase, but you can certainly choose to do that manually as you would for major bumps. The point for us, and I would think with this project in general, is that if we say we only want patch and minor semver changes to be auto-merged, we're saying that we want those that are more likely to be "safe" and not to break our apps. Since the official semver spec makes a special statement for 0.x.y, I'm arguing for a special delineation for this category to reflect this, and then let the person configuring this action decide what they want. I'm willing to contribute a PR for this but won't take the time if it's unlikely to be approved.

I'm trying to discern if https://github.com/ahmadnassri/action-dependabot-auto-merge/pull/43 gives us this flexibility in any way, and I don't see that it does. It'd be common to have 0.x.y in both regular deps and devDeps, which means dependency_type probably doesn't help us, and we're not wanting to have to whitelist every single dep by name.

In any case, thanks for your time and for putting this project out there. We have already benefited from this, and we're preparing for Github's native Dependabot offering, which doesn't include auto-merge. Co-incidentally, the previous auto-merge offering from Dependabot didn't auto-merge 0.x.y as part of semver:minor, so there's precent for that sort of thing.