Maybe don't release a major version every week.

Alternative: Use version 0 which explicitly makes no guarantees on API stability.

We tried to avoid doing breaking change, however, we have so many services adding new features, which is not easy to control breaking changes, but we also need to follow Go version bump rules, have to do major version bump for breaking changes. If we don't import version in our xxx.go files, the released packages can't be added to https://pkg.go.dev/github.com/oracle/oci-go-sdk?tab=versions, so it is really painful for users to use. I think not only us, but others also have the same problem, I checked some other cloud go sdk, they also have to add breaking changes, however, they did minor and patch version bump, did not follow Golang version bump rule, so I really hope Golang can resolve this, thanks!

Should this issue be considered a proposal? If so please do:

@gopherbot, please add labels Proposal,modules

Edit: Oops, gopherbot seem a little too eager

@D1CED , thank you so much!

@ianlancetaylor can this issue be added to the proposal milestone and slot into the Incoming proposal project section.

This proposal should also be retitled to something like: proposal: import current version by default if no version specified
But I think this needs some more clarification by the author.

Any immediate thoughts?

Thanks.

Do you mean you want consumers of your library to be able to just automatically get the latest version at all times, or just that your library doesn't have to refer to itself using the /v{num} format inside its own packages?

Since you ask, I'll make this a proposal, but I don't see how it could possibly work. In Go different packages must have different import paths. Permitting the same import path to mean different versions of a package can't work.

CC @bcmills @jayconrod

Related: #40323

This goes against a key design goal of modules: building with a reproducible set of dependency versions. If a module author releases a new major version with incompatible changes, their users shouldn't immediately be broken by those changes.

we are developing new services and sometimes also need to update the existing service APIs, so making breaking changes are somehow unavoided

Can you give more detail about why breaking changes are unavoidable? This proposal seems to be aiming to undo an explicit design element of #24301, and revisiting that design means that we need evidence that was not already taken into account when the decision to accept that proposal was made.

Looking at the changelog in https://github.com/oracle/oci-go-sdk/blob/master/CHANGELOG.md, I see that the breaking changes seem to fall into a number of categories, many of which are addressed (directly or indirectly) in https://blog.golang.org/module-compatibility.

To take a few examples:

• Header Parameter Etag in Operation ListAppCatalogListingResourceVersions response was removed from the Core service
• Property VnicId in model Ipv6 was removed from from the Core service
• Const GetObjectArchivalStateAvailable was removed from operation GetObject response from the Object Storage service

Why did these need to be removed, instead of deprecated?

• Property IdcsAccessToken in model CreateBlockchainPlatformDetails changed from optional to required in the Blockchain Platform service

Why was it necessary to make that property required? If it was necessary in order to reduce user error (perhaps from users forgetting to set that property when appropriate), why was it done as a breaking change to an existing model rather than, say, deprecating the old model and introducing a new, corrected one?

• Method GetLifecycleState()'s return type in the interface ConfigurationSourceProviderSummary was changed from ConfigurationSourceProviderSummary to ConfigurationSourceProviderLifecycleStateEnum

Why was the type of the existing method changed, rather than introducing a new method with a different name and return type and deprecating the existing method?

All of these changes look to me like very reasonable things to do in an evolving, unstable API — but an evolving, unstable API would be major version 0, not a “stable” major version. (See https://semver.org/#doesnt-this-discourage-rapid-development-and-fast-iteration and https://semver.org/#if-even-the-tiniest-backwards-incompatible-changes-to-the-public-api-require-a-major-version-bump-wont-i-end-up-at-version-4200-very-rapidly.)

For a Go package at a stable major version, the expectation is that the package author will make a significant effort to avoid unnecessary breaking changes — even if that means keeping around parts of the API that would otherwise be deprecated or redundant or providing shims to translate from an old way of doing things to a newer way.

A couple questions for clarification:

1. Am I right in the assumption that an import would behave differently when it is used in a package of the current module versus an external module?
2. How would that interact with importing a version v0 or v1 of the same module?
3. How would that interact with releasing a newer version?

Examples:
Lets assume the latest major version of mymod is v5.

-- mymod/mypkg.go@v5 --
import "mymod/otherpkg" // this would resolve to "mymod/v5/otherpkg"

-- othermod/mypkg.go --
import "mymod/otherpkg" // this would resolve to "mymod/v1/otherpkg"

3. Now we release a new major version of mymod (v6).

-- mymod/mypkg.go@v6 --
import "mymod/otherpkg" // resolves to "mymod/v6/otherpkg" as it is the latest

-- mymod/mypkg.go@v5 --
import "mymod/otherpkg" // applying 'latest' literally this resolves to "mymod/v6/otherpkg" which breaks this version

All of these changes look to me like very reasonable things to do in an evolving, unstable API — but an evolving, unstable API would be major version 0, not a “stable” major version.

"Stable" and "unstable" are not well-defined terms; even the links to the SemVer FAQ make this clear. They are relative and context-dependent. It is entirely possible that a major version bump each week means a project in one domain is "stable", and that a major version bump every six months means a project in another domain is "unstable".

The definition you're using here is toward one end of the spectrum, but not every module consumer requires, or even benefits, from this stricter definition of stability. And because Go modules has a monopoly claim on package management, it is not free to assert these more specific definitions of subjective terms, without artificially limiting participation in the ecosystem.