Notification of breaking changes

[jgollenz]

It seems some people are using zigup to get the nightly version of zig. And some people also seem to occasionally miss new breaking changes in master. Wouldn't it be great if zigup would notify you about any breaking changes that happened between the last time you fetched? I imagine it a bit like how changes in plugins are displayed when running :PackerUpdate in neovim:

Here you can see no breaking changes because there weren't any, but they would be marked red. The other commits might be interesting for some, but not essential. The feature would only be relevant for master.

[jgollenz]

However, this feature would lose a lot of its utility once Zig reaches 1.0 (presumably). But until then, I think it might be helpful.

[marler8997]

This is a cool/interesting idea. I have some thoughts as to how something like this could be done. Did you have any ideas in mind as to how you would classify changes as breaking?

[jgollenz]

I was simply thinking of looking for commits with breaking, like packer does. I've seen both (breaking) and [breaking] in the git log. I don't know if there are any existing conventions regarding that in the Zig community.

[jgollenz]

@marler8997 could you please share your thoughts on the subject? In light of this, this feature could become very beneficial for some time.

[marler8997]

Alot of thoughts come to mind, mostly about how to classify/detect/enforce breaking changes. It seems to me that a perfect solution here couldn't exist since there's no way to know for certain whether a different compiler would break a project before actually trying to build/test it. So the best we can do is some sort of heuristic. We could manually maintain a list of versions along with breaking changes, maybe even categorize types of breaking changes. We could also establish a convention in the zig repo for this to include this information within commit messages. However, if we forgot to include the details of a breaking change in a commit then there's no way to go back and fix that. For this reason it seems like it would be best to maintain this information outside of the commits themselves so we could go back and add this information at any time. This would also keep the door open to improve how we categorize/classify breaking changes if desired.

I also have questions about the best interface to include this information in zigup, if it would make sense at all. Maybe this sort of thing should go into zig itself rather than zigup? For example, if a project is currently on version A and wants to upgrade to version B, then maybe zig could provide a zig show-breaking-changes A B. If we included this information in zig, that would make it pretty easy to also include it in zigup when the user wants to change their default compiler.

Anyway those are just some of my thoughts. I see potential here but I'm not certain what direction we want to go and the considerations go beyond what I control with zigup which makes it more difficult to pick a direction.

P.S. zigup doesn't have an update command, but, an update operation would be very similar to runnng zigup master if the current default compiler is also pointer to master. I believe we can detect this scenario and this would probably be the situation to print breaking changes like packer does.

P.P.S sorry more thoughts I forgot to include. This is related to an experimental project I've been playing around with (https://github.com/marler8997/zig-pkg-db). The idea is to maintain a database of zig packages and the latest versions that build and pass the tests. The zig toolchain would also be considered a dependency like any other and would therefore be able to detect when any zig compiler changes breaks any zig package in the database.

[jgollenz]

I also think it would not be possible to tell whether a project will be broken by a new version (without recompiling the project, but zigup may be run at any place without the context of a specific project), but it still is a good idea to notify people that something breaking has changed, so that they can expect it. Maintaining a list of breaking changes is certainly doable and grants more flexibility, but I think that the baseline should still be a convention in the Zig repo. Not everyone might use zigup and have their own way of detecting breaking changes from commit messages (whether that is done manually or automatically). Its just good form for a project of Zig's size/seriousness and from what I see they are already trying to do that. zig show-breaking-changes a b sounds enticing, but I'm not sure how easy it is to convince people of adding a new cli command that will probably be less valuable over time. You probably have more experience than me in that regard. Also, does the Zig toolchain have any notion of its own version in relation to another? Too me it sounds more like a zigup thing really, but I'd like to hear what others think.

Ad P.S.: yes, that's exactly how I use plugins in packer. Usually they have rolling releases and you just run :PackerUpdate and scroll through the list of commits to see if anything breaking was introduced.

Ad P.P.S.: sounds interesting 👍 what is the goal of it? Notify package maintainers as soon as one of their packages breaks on a new version? An interface for people to check whether their build.zig will run on a given version? I cannot see the repo, as it's private.