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.
The article addresses both of these pretty clearly. Semantic versioning gets borked with reverts and the automatic changelog is targeting the wrong audience
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Live rankings currently have Mac OS X first... h... how?
Apple make so so much wonderful hardware! They always have. Their software on the other hand is near universally awful. I love my Macbook, but my gosh, I do not love whatever the latest flavour of macOS is that Apple have decided to throw on their update servers this year. It just so happens that I also enjoy Unix, so I spend a lot of my time in a terminal - but Apple don't get to claim credit for that!
EDIT: OK. It just refreshed and is now showing Mac OS X as 36th over all. Crisis of faith averted.
I want to speak up for OS X. When it came out, and for years afterward, it hit an amazing sweet spot of looks cool, runs browsers well, runs MS well, runs Adobe well, full Unix shell, added great new features every year. There is a reason it became extremely popular with web devs, as the web was taking over the economy.
A closed local firewall blocking all inbound by default. Spotlight indexing. Time Machine backups. Flexible screenshot tools. Print anything to PDF. Lots of useful trackpad gestures. And after Intel, we got Rosetta, Boot Camp, easy Windows virtualization like Parallels, etc. That’s all off the top of my head, but for sure OS X had Microsoft on their back foot for years. Gates used to yell at his team about it.
I'll definitely give you Rosetta, and even more so Rosetta 2. Spotlight too, at least in principle, but it has had its fair share of dodgy behavior over the years. I'm not really sure about the others.
There's certainly always been fantastic software available for Mac. However, it was almost never built by Apple. It sort of felt like someone one day needed a FireWire port, so they bought a Macintosh. Then they must have told a close friend working at Macromedia they needed some software - and it was all just inertia from then on.
I must admit, this is one area I've found LLMs to be surprisingly strong. They're REALLY good at reverse engineering obscure platforms, languages, game engines; and quickly throwing together super hacky tooling.
I was able to reverse engineer the PS4 edition of "New Game!: The Challenge Stage", which was never released in English. I've now fully translated it, added proper text wrapping and additional text boxes where text would now overflow. Along the way I've fully decompiled (with byte exact recompilation) the Squirrel scripts for the entire game, built atop the game engine of a now largely defunct game studio. Prior to this I hadn't even heard of Squirrel scripting language. I had most of this done in under 24 hours.
I'm not in any way a part of the visual novel community. I just did this because I enjoyed the New Game! anime way more than a near(?) middle aged man probably ought to.
P.S. My condolences to Yorhel's friends and family.
Brings back memories of how I did much the same for the PSP spin-off VN of the GA Geijutsuka Art Design Class manga/anime (that, of course, also originated from Manga Time Kirara and also had a big focus on art), although those were pre-LLM times. It even used Squirrel scripts too!
I second the condolences, tremendous loss for the people who knew Yorhel, as well as for the VN and open source communities.
Thanks, Eric; for this, and for my start as a software engineer — my first commercial development work was consulting as an 18 year old building games with C4. I'm really glad Slug was able to find commercial success for you in the way that C4 unfortunately wasn't able to.
For those of you who aren't familiar with Eric's work, he's basically the Fabrice Bellard of computer graphics.
Although this is a facetious take, instructing a robot to follow recipes is a fantastic introduction to coding. I added a visual scripting layer to Overcooked so kids can program robots to make all sorts of dishes (Sushi, Pasta, Cakes etc.)
I think this is a great introduction to logical thinking and coding. The overcooked scripting layer looks awesome and very polished. Reminds me a bit of Scratch (the programming language).
Are you going to make it available to others?
There are also video games based on this concept, e.g. Bots are Dumb. So maybe your scripting layer it could even become its own commercial game.
Breaka Club is still very early days. Current focus is in person, but the plan is to offer an online club experience also. I'm not quite sure what that will look like just yet. Ideally yes, I'd love to make this available to others.
We're also currently building Breaka Club's own game, which is where the majority of development efforts are focused. However, since we already have the Overcooked coding experience, we haven't prioritized the visual script layer for this game just yet - it's on our roadmap.
Presently, our game is more of a cozy farming RPG / world building sandbox, with a no-code solution for world building:
The recent Netflix Games edition of Overcooked with K-Pop Demon Hunters is cool, but not nearly as cool as kids coding and playing their way through Overcooked levels in our custom educational mod for Overcooked:
And last week I also put together the first release of MoonSharp in ~10 years; Lua runtime for Unity. That's not for Breaka Club though, I also consult for Berserk Games on Tabletop Simulator:
Somewhat coincidentally, MoonSharp (the scripting engine Moongate based their Lua runtime on) is alive and kicking again. There hasn't been a release in ~10 years, but I published a beta for v3.0.0 a few days ago.
I'm not the creator of MoonSharp, just a maintainer on Github (who has honestly done very little). However, I consult for Berserk Games, and we have use MoonSharp as the scripting runtime for Tabletop Simulator.
Hi! I've been following your work on GodotJS for a while now. Really cool stuff man, thanks for all the improvements you landed in GodotJS!
I think most of the people using Godot are not aware how powerful and ergonomic GodotJS actually is. All the intellisense and completion suggestions goodness when using GodotJS is a godsent.
Can you tell us a bit more about how making breaka club with GodotJS has been going for you?
- Are you using Godot as kind of a rendering frontend while your TypeScript code is rather self-contained and only interacts sparingly with the APIs exposed via GodotJS or is everything deeply intertwined? I'm curious because I'm still looking for a good GDScript replacement. I really dislike GDScript so much :(
- How has performance been? I'd imagine V8 with JIT be a lot faster than GDScript and probably within 2-3x of C#? But I guess one wouldn't be able to use V8 JIT on consoles or iOS? I wonder if the performance hit would be tolerable.
- Do you still have high-performance code you write with e.g. godot-cpp and if so, how's easy is it to make those things interact?
- I saw that there have been thoughts about migrating GodotJS to a GDExtension but it's not easy it seems? Would be a great long-term goal imo because not having to use a custom engine build and instead just plug in a GDExtension would be pretty convenient.
- I assume that one cannot use stuff like the node file system API or such things and one has to restrict themselves to JavaScript/TypeScript code that would also run in the browser?
Sorry for the flood of questions, no need to answer them all. Still curious about all of those things :)
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.
reply