haskell
new version number suggestions seem wrong?
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
?
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).CShouldn'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?
