| ▲ | Benjamin_Dobell 3 hours ago |
| Odd. The main reason to use this style of commit message is for CI/CD automation. EDIT: I didn't see this covered in the article on my first pass. It is covered though. My apologies. The type of the commit informs the automated workflows how to handle the commit. This is why it comes first. For example, if you're performing CD, if you only commit a bunch of `fix: ` then only your semantic versioning patch version number is incremented. If you commit a `feat: ` then it's a minor version is bump. `feat! ` is a major version bump. Even if you're not using CD for releases, semantic commit messages are sometimes used to automate change log generation. Granted, your change logs should not typically include the Git commit messages themselves — those are developer facing, not user facing. |
|
| ▲ | mcluck 3 hours ago | parent | next [-] |
| The article addresses both of these pretty clearly. Semantic versioning gets borked with reverts and the automatic changelog is targeting the wrong audience |
| |
| ▲ | beart 2 hours ago | parent | next [-] | | The article is wrong about reverts (in my opinion). If a breaking change is introduced, and then removed, the removal should also most likely be considered a breaking change (both the addition and removal are changing your API). So it is correct that a major version bump should occur when reverting. Once a package has been published, the ship has sailed. | | |
| ▲ | layer8 2 hours ago | parent [-] | | The issue is that if there was no release in between, or only a beta or similar, you now have two breaking changes indicated by the commits, although in sum there is none since the last official release. | | |
| ▲ | beart 2 hours ago | parent [-] | | That's true, but depends on your workflow and release strategy. If you are releasing upon every push to main/master (following what semantic release and conventional commits provides you in terms of automation), then it makes sense to perform major version bumps for the reverts. If you have a manual release strategy, then it might not make sense to use these tools in the way they have been designed. | | |
| ▲ | layer8 2 hours ago | parent [-] | | If you have actual dependents in a SemVer fashion, then this isn’t useful for those still on the prior version. What you’d rather do is decrement the major version again because it’s compatible with the prior version again. Those dependents who already upgraded to the interim version have to consider another breaking change regardless. And if you don’t have these kinds of dependents, then the versioning scheme isn’t important anyway. | | |
| ▲ | claytonjy an hour ago | parent [-] | | release-please[0] allows you to do a manual version override in a commit, which would allow you to decrement the major version upon reverting a breaking change I think that could be simplified, so the tool can tell that a commit is reverting a breaking change and thus the version should be decremented, but at least there's an escape hatch. [0]: https://github.com/googleapis/release-please |
|
|
|
| |
| ▲ | Benjamin_Dobell 2 hours ago | parent | prev [-] | | My apologies, I missed this on first read due to the indentation style. That said, I don't agree on the commentary. Why on Earth are people not writing commit messages for their reverts? They should have semantic commit messages just the same as any other commit. Unless the point is that they're not following per-commit CD, and if you commit then revert that commit before a release was made. That sounds like a process failure. Which of course, process isn't infallible, and neither is the automated version management. If you screw up, use an escape hatch — just like reverting a commit that had previously gone through code review and been merged. Re: change log generation. The article says change logs shouldn't have commit messages. I agree. Many tools (e.g. Changesets https://github.com/changesets/changesets) use the semantic commit type to sort change log entries, but require you to write those user facing change log entries separately. |
|
|
| ▲ | xer0x an hour ago | parent | prev | next [-] |
| +1 I used this style to version bump, and wish the article gave suggestions on working alternatives. Lately I use CalVer instead of SemVer, so it hasn't been an issue. I like the idea of smart auto-bump for versions. |
|
| ▲ | 2 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | what 2 hours ago | parent | prev | next [-] |
| Use some convention for git trailers then. Having “fix” or “feat” in the commit title does not provide any useful information to someone scanning the log. |
| |
| ▲ | Benjamin_Dobell 2 hours ago | parent [-] | | How... how is this not obviously the absolute very most useful information? When I encounter a bug in a dependency of mine. Before I worry about submitting a PR, the very first thing I do is grab my version number and check the commit logs for fixes since my version number. If I'm trying to decide whether I should bother upgrading, I scan the log for new features. It's the title, not the details. The commit message body should contain MUCH more detail than the title. If you don't like it because it looks ugly. Sure, that's subjective. And actually, I agree. Because it's standardized though, Git interfaces could even be configured to trim this off and provide different visual styles for the different kinds of commits. The types could be used as search filters too etc. Now, I get people don't like the look of them. Neither did I when I first saw them. Then I started using them and found them useful. It's fine, people have different preferences, it's just a convention and it's not going to work for every project. The article itself just doesn't seem to hold any water. | | |
| ▲ | compiler-guy an hour ago | parent | next [-] | | If one is writing trailers and custom formatters, then probably the information that the formatter uses should be even more structured that sticking it in the subject line. | |
| ▲ | jacobsenscott an hour ago | parent | prev [-] | | This is what a changelog is for | | |
| ▲ | Benjamin_Dobell an hour ago | parent [-] | | It's really not. If I'm at the point of contributing a PR to a dependency, I've already identified the root cause in detail. There's no way a change log should be going into that level of detail, or else you're just duplicating the Git log for no reason. Will the change log make mention of fixing the bug? Perhaps. But I'm going to want to read the technical details of the fix to make sure they've specifically addressed my issue, and not just a similar problem. What is the performance impact of the fix? Are there security implications they've explained in the commit message. I'm a software engineer, not an end user, I want the technical details of my dependencies. |
|
|
|
|
| ▲ | drfloyd51 3 hours ago | parent | prev [-] |
| No no. You see we need to get rid of conventional commits so AI can make commits easier. |
| |
