new version number suggestions seem wrong?

[benjaminselfridge]

In the decision flowchart, the major version bump leaf says something like

Your new version number should be (A+1).B.C or A.(B+1).C

Shouldn't it rather say

Your new version number should be (A+1).0.0 or A.(B+1).0

?

[hasufell]

I don't think so. Have you read the spec? It doesn't define what to do with C when you have eg a breaking change. It's up the the maintainer.

[sjakobi]

@hasufell I think the issue that @benjaminselfridge wanted to point out is that the flowchart recommends keeping B and/or C the same when bumping A or B.

Instead the flowchart should make it clear that the new B and/or C are free to choose. Something like this maybe?

Your new version number should be (A+1).B'.C' or A.(B+1).C' where B' and C' may be freely chosen but are usually 0

[benjaminselfridge]

@hasufell Right -- didn't mean 0 necessarily, but it looks like it's telling you to keep the same B and C after incrementing A.

@sjakobi that's about what I had in mind.

[frasertweedale]

This was addressed in PR https://github.com/haskell/pvp/pull/20/files.

Also a duplicate of issue #25.

Suggest to close.

Though it would be nice if we could see the enhancements actually deploy to pvp.haskell.org :)

[andreasabel]

In the decision flowchart, the major version bump leaf says something like

Your new version number should be (A+1).B.C or A.(B+1).C

Shouldn't it rather say

Your new version number should be (A+1).0.0 or A.(B+1).0

Remark: More correct would be:

Your new version number should be (A+1).* or A.(B+1).*

as you do not need to preserve the number of positions in the version string. However, it might be better practice to commit to a fixed number of positions.

[Kleidukos]

Any chance we could get a new deployment of the repo, since the current version attracts new tickets that are duplicates of this one?