Closed notpeelz closed 5 months ago
It's funny to think that a bit over a year ago I naively thought this would be a simple shell script...
Thanks! I'll investigate everything.
I'll be committing changes as fixup!
commits instead of amending my existing commits. This is so that it's easier for you to understand what changes have been made at every step of the review.
Once I get your approval for merging, I'll rebase and squash the fixup!
commits to clean up the history.
Just make sure not to merge my branch until then, because GitHub doesn't automatically squash these special commits.
I removed the vscode-specific pyright/pylance config and replaced it with an editor-neutral pyproject.toml
config: https://github.com/microsoft/pyright/blob/main/docs/configuration.md#sample-pyprojecttoml-file
Let's go ahead with this. It will warrant bumping version up to 0.14 and a [Breaking]
note about everything, including plugin paths.
Great!
Should I add a new commit to bump the version and write about the breaking changes there?
BTW, have you considered using something like conventional commits? The "breaking changes" part is signaled by the exclamation mark, e.g chore!:
, fix!:
, etc
Should I add a new commit to bump the version and write about the breaking changes there?
Yes.
BTW, have you considered using something like conventional commits?
Good idea!
I don't want to push my luck, but would you be open to adopting the semantic versioning version format? It would make sense since you're already using a 3-component version format for non-zero patch releases. e.g 0.14.0 instead of 0.14
No problem )
I didn't mark the version bump commit as breaking, since it's technically not a breaking change itself. The breaking commits have chore!
, fix!
, etc.
I hope that's OK :)
Congrats!
Thank you! I appreciated our conversation.
This should make it easier to refactor (#16).
You can try it out like this: