Open benjaminselfridge opened 4 years ago
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.
@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
@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.
This was addressed in PR https://github.com/haskell/pvp/pull/20/files.
Also a duplicate of issue https://github.com/haskell/pvp/issues/25.
Suggest to close.
Though it would be nice if we could see the enhancements actually deploy to pvp.haskell.org :)
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).*
orA.(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.
Any chance we could get a new deployment of the repo, since the current version attracts new tickets that are duplicates of this one?
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
?