Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix semver not fully covered #1081

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Lee-W wants to merge 1 commit into master from fix-semver-not-fully-covered
Closed

Conversation

Copy link
Member

@Lee-W Lee-W commented Apr 24, 2024

Description

1.0.0-reallyweird is a valid semver but not yet covered by commitizen. Possible solution could be #950 (comment)

Closes: #950

Checklist

  • Add test cases to all the changes you introduce
  • Run ./scripts/format and ./scripts/test locally to ensure this change passes linter check and test
  • Test the changes on the local machine manually
  • Update the documentation for the changes

Expected behavior

Steps to Test This Pull Request

Additional context

Copy link
Member Author

Lee-W commented Apr 24, 2024

Currently, only test cases are added. Will need to find some time to wrap it up. Feel free to take over if anyone's interested in it 🙂

Copy link
Member Author

Lee-W commented Apr 25, 2024

I think this one would be a bit tricky 🤔 prerelease can be anything for semver. Thus, bump prerelease might not make sense to semver. e.g., what should be the next version of 1.1.0-test @woile @noirbizarre WDYT?

Copy link
Member

woile commented Sep 12, 2024

I completely missed this. I don't know the answer, but I think we could stick to adding the 0 at the end (?)

1.1.0-test.0
1.1.0-test.1
1.1.0-test.2

Similar to semver:

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1

And we could assume anything unknown is before alpha (?)

Copy link
Member Author

Lee-W commented Nov 10, 2024

I completely missed this. I don't know the answer, but I think we could stick to adding the 0 at the end (?)

1.1.0-test.0
1.1.0-test.1
1.1.0-test.2

Similar to semver:

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1

And we could assume anything unknown is before alpha (?)

Sounds like a good idea 🤔 I'll get back to this one when I have more bandwidth

Copy link

dhmemi commented Dec 5, 2024
edited
Loading

I completely missed this. I don't know the answer, but I think we could stick to adding the 0 at the end (?)

1.1.0-test.0
1.1.0-test.1
1.1.0-test.2

Similar to semver:

1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1

And we could assume anything unknown is before alpha (?)

Perhaps this could be done by having the user configure a prerelease word list and bump to the next item in the list. If the current prerelease is already the last word, upgrade the previous patch version.
In the case where the user has not given a word list, ignore prerelease, and retain any subsequent text after 1.0.0- as is (Behavior consistent with only one word in the word list) ?

e.g.:

with prerelease config:

prerelease = ["test", "beta", "anyword"]
1.0.0-test < 1.0.0-beta < 1.0.0-anyword < 1.0.1-test

no prerelease config:

1.0.0-test < 1.0.1-test < 1.0.2-test

Copy link
Member Author

Lee-W commented Dec 6, 2024

Sounds like a valid idea 👀

@@ -64,6 +64,7 @@
(("1.0.0alpha1", None, "alpha", 0, None), "1.0.0-a2"),
(("1", None, "rc", 0, None), "1.0.0-rc0"),
(("1.0.0rc1+e20d7b57f3eb", "PATCH", None, 0, None), "1.0.0"),
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not semver but PEP440

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@woile woile Awaiting requested review from woile woile will be requested when the pull request is marked ready for review woile is a code owner

@noirbizarre noirbizarre Awaiting requested review from noirbizarre noirbizarre will be requested when the pull request is marked ready for review noirbizarre is a code owner

1 more reviewer

@gsemet gsemet gsemet left review comments

Reviewers whose approvals may not affect merge requirements
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Help wanted: commitizen 3.x not supoort generate CHANGELOG with tag format like v1.0.0-release

AltStyle によって変換されたページ (->オリジナル) /