v0.1.0 is a rehoming of package ff on major version 0. All future development will occur on major version 0. There are no changes in functionality from the latest MINOR.PATCH release of major version 3.

[thomasf]

This seems like a very breaky change.

You should probably start over in a new repository instead if you want to break the version assumptions.

[thomasf]

Everyone that installs using go get to install this dependency will get version 1.7.1 and never the "latest" version?

If the go tool gets a feature to suggest/assists with major version upgrades it will start suggesting v3.

Does going back to v0.1 mean that there will be breaking api changes in this module? This makes makes program development more painful.

[peterbourgon]

You're right, I need to deprecate all v1.x.x versions. Thanks for the reminder.

[peterbourgon]

Using major version 1+ was a mistake, and I need to undo that mistake as responsibly as possible without using a different import path.

[peterbourgon]

go get github.com/peterbourgon/ff chooses v1.7.1 despite it being deprecated. As far as I can tell that's bug in modules. Unfortunately I am unable to communicate this to the team.

[peterbourgon]

I've reverted to major version 3 until I can resolve these problems. I apologize for the trouble in the interim. Please re-open if there's something else.

[ChrisHines]

I don't think deprecation by itself is strong enough for what you're trying to do. I think a retract directive is the tool you're looking for.

When a module version is retracted, users will not upgrade to it automatically using go get, go mod tidy, or other commands. Builds that depend on retracted versions should continue to work, but users will be notified of retractions when they check for updates with go list -m -u or update a related module with go get.

[peterbourgon]

Yep, I think you're right. I'll test this somewhere else first.

[thomasf]

I still think that the best solution is just to change to a new repository. no risk of confusion by current or future tools and no need to make current versions not stop working.

Even the change to v0 implies an import path change so moving to a new repo won't be much of a difference.

In any case, if the plan is to revert to v0 to allow breaking changes forever I will have to use a fork instead. I have way too many programs that depends on at this point ff and I don't want go get to break builds.

If the reason to go to v0 is to finalize the API and the then move to v1 and never to v2 is at least approachable.

[peterbourgon]

I still think that the best solution is just to change to a new repository. no risk of confusion by current or future tools and no need to make current versions not stop working.

I understand this position, but I'm not willing to give up the peterbourgon/ff name.

In any case, if the plan is to revert to v0 to allow breaking changes forever I will have to use a fork instead. I have way too many programs that depends on at this point ff and I don't want go get to break builds.

It's my opinion that Go modules asserts a model of compatibility that's incompatible with the overwhelming majority of all software, this repo included. It's irresponsible for modules maintained by individuals, or groups of open-source contributors, to opt in to major version 1+ in this model. I released major versions 1-3 before I understood these problems, and that was a mistake which I need to correct.

This isn't a problem for you, though. You get to decide when to update the dependencies for your project, it's not an automatic process. And there's no reason to update this dependency if you don't have specific need to do so.

[thomasf]

Maybe it's not that bad for a library like this. It's likely that a command line parsing module only will be used by the main program so you might never have large issues.

It becomes unsustainable to not use semantic import versionen is when multiple dependencies you have depend on different incompatible versions of some module.

This is a major pain point in other programming languages that does not support multiple major versions of packages. Python is such a language and I have had this problem many times. Only a few package authors understand this, the AWS boto is such a package when the main import module is boto and boto3 and that decision alone has saved me so much headache because libraries and program code can be migrated over time without a total breakdown. I actually even have a few of these issue right now in large python projects that are more or less deadlocked into old versions of stuff because upgrading would require upgrading 20+ projects at once and some of their interconnected dependencies.

Java and JS both have support for any combination of any versions using scoped loading (class loaders and closures). I find these solutions horrible to work with and understand how a project dependency tree actually works.

There are definitely not obvious single best solution here but my opinion is that semantic import versioning actually is the least painful way to do this.

[peterbourgon]

I'm 100% for semantic versioning. I'm 100% against semantic import versioning, for the reasons in the linked article. Specifically,

when multiple dependencies you have depend on different incompatible versions of some module.

It is my opinion that this condition is extraordinarily rare, and when it does crop up it's an artifact of a pathological codebase.

This is a major pain point in other programming languages that does not support multiple major versions of packages.

I don't agree. This is a niche problem.

Only a few package authors understand this, the AWS boto is such a package when the main import module is boto, boto2 and boto3

Very few packages (modules, etc.) are imported by enough consumers that this condition is likely to manifest. Maybe boto is one of them, I don't know. If it is, then boto2/boto3 is IMO a more appropriate solution than SIV.

[thomasf]

I'm 100% for semantic versioning. I'm 100% against semantic import versioning, for the reasons in the linked article. Specifically,

I guess we just have different previous experiences that guides us on this point.

Very few packages (modules, etc.) are imported by enough consumers that this condition is likely to manifest.

Probably but but go module authors are typically pretty good at actually using SIV, mostly by just staying on 1.x and never breaking backwards compatibility but even pretty good at not even doing it at 0.x. I don't think that the Go eco system is old enough experiencing the long term effects of this yet though and if most modules actually use SIV it won't even be as noticeable.

I think that maintenance and dependency upgrade progress starts to vary more when libraries becomes older, like 10-20 years old. The Go modules feature itself is only 3 years and before that there was a wild west of Go package manages for a few years. We haven't even seen what long term Go package maintenance looks like.

If it is, then boto2/boto3 is IMO a more appropriate solution than SIV.

That is semantic import versioning. You install/import boto and/or boto3 just like it would have been boto and boto/v3. It's just not SIV defined by any soft or hard rules of the package system itself.

I've come across this issue a bunch of times over the last decades and it's everything from tedious to really complicated to deal with.

For me it typically happens for code that has been in production long enough so that major versions transitions is happening at varying paces in the dependency tree.

I am not trying to start a debate here, I have now clarified why I believe that SIV probably is the least worst solution so I won't bother you any more with it.