Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buf doesn't recognise "v0" as a valid version #1335

Closed
mikhainin opened this issue Aug 12, 2022 · 4 comments
Closed

Buf doesn't recognise "v0" as a valid version #1335

mikhainin opened this issue Aug 12, 2022 · 4 comments
Labels
Feature New feature or request Won't Fix Deferred tasks that are currently not addressing

Comments

@mikhainin
Copy link

In our company, we have a standard that version "zero" (v0) is a development branch however, buf only accepts positive numbers as a version suffix.

Basically, a typical proto-file looks like this:

syntax = "proto3";

package bumble.xapi.recommender.v0;

But when we run buf lint against it, we will get:

recommender.proto:3:1:Package name "bumble.xapi.recommender.v0" should be suffixed with a correctly formed version, such as "bumble.xapi.recommender.v0.v1".

I can understand why it is so, I just wanted to check if there's anything we could do about it. Maybe add a specific option for buf. Or that rule about "positive number" might be not that strict.

What are your thoughts?

@amckinney
Copy link
Contributor

I know you've said that you already understand, but I'll include the reasoning for posterity - the PACKAGE_VERSION_SUFFIX rule suggests that such unstable, in-development packages should actually be packages suffixed with alpha1, or something similar (e.g. v1alpha1), instead of v0.

Maybe add a specific option for buf. Or that rule about "positive number" might be not that strict.

Both of your suggestions are technically reasonable, but there are some caveats. The PACKAGE_VERSION_SUFFIX rule would become more permissive, but some organizations might actually depend on the fact that it prevents users from using the v0 suffix (they might want that version to be outlawed, for example). So although it feels like a backwards compatible change, it would potentially break certain use cases.

In this case, we'd need to add a new configuration option to the buf.lint configuration key, or build out a new lint rule that you can configure (e.g. PACKAGE_VERSION_SUFFIX_WITH_ZERO - that might not be the name we'd actually go with, but you get the idea).

With all that said, we could implement one of these features, but I'd rather encourage you to adopt the standard package versioning structure that we're promoting. One of Buf's primary goals is to make Protobuf consistent everywhere, and that's exactly what the DEFAULT set of lint rules helps us achieve. The more differences we accommodate, the more frequent there will be differences.

What are your thoughts?

@amckinney amckinney added the Feature New feature or request label Aug 12, 2022
@marekbuild marekbuild added the Wishlist Things we'd want in the future label Aug 12, 2022
@amckinney amckinney added Won't Fix Deferred tasks that are currently not addressing and removed Wishlist Things we'd want in the future labels Aug 15, 2022
@amckinney
Copy link
Contributor

I'll close this as-is - we likely won't get around to this one.

@nemith
Copy link

nemith commented Feb 22, 2024

Buf documentation actually lists v0 as recommendation for unstable apis https://buf.build/docs/reference/protobuf-files-and-packages#packages

Probably should match the documentation with the lint expectations?

@nemith
Copy link

nemith commented Feb 22, 2024

I think v0 (no guarantees on api stability) is different than alpha or beta. You can compare this to the equivelent v0 scheme used for Go which does the same. I would agree that v0 shouldn't be default but it's small and susinct and implies different intentions than an alpha or or beta moniker.

I also disagree that a lint change is a breaking rule. I think that is a bit of a stretch in reasoning.

So i think this is unfortunate but understandable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature New feature or request Won't Fix Deferred tasks that are currently not addressing
Projects
None yet
Development

No branches or pull requests

4 participants