Given the growing complexity of
gtk-rs release and the upcoming number of related questions to this topic, I thought it might be interesting to have a little post on how it worked and how it now works. I talk a bit as well of the reasons of why
gtk-rs isn't a single repository.
Like I said just above, I changed very recently how we release a new version of
gtk-rs. With the following explanations, you'll understand very quickly why.
First point, the
gtk-rs organization is huge in term of number of crates: we have 26 of them. Yes, 26. And the funniest part: they all depend on each other, but that's not all! The current architecture is as follow:
cratebranch (which corresponds to the current released crate) and a
masterbranch (which is the development branch). (Though there is an exception here: the
examplesrepository has a
mastercorresponds to the current relese.)
So the first step is to update the crate version inside the
master branches and update all its
gtk-rs dependencies' version as well.
Then we merge changes from the
master branches into the
Next, we open pull requests to the
Once all pull requests have been merged, we publish all crates to crates.io (in a specific order, otherwise it doesn't work because of dependencies), starting from sys-crates.
Good, seems like we're mostly done, no? What could be missing? Oh, the documentation!
Let's update it then! For every non-sys crates, we have to generate the documentation by enabling all features. Some of you may have notice it, but
gtk-rs repositories don't contain documentation in their source code. The reason is simple: for licensing issues, we store all of them in a specific repository: lgpl-docs.
In the old times of
gtk-rs, I wrote a tool (with the great help of gkoz!) to add and remove documentation from a
Rust source code: rustdoc-stripper. We use it to put back the documentation before generating it.
Once done, we push, make a pull request and merge it. That's it, the documentation has been updated as well!
Now two things are remaining:
The first one is quite quick to be done, the second one a lot less (Thank you so much @EPashkin for helping me doing it! T_T).
From all this, I assume you now have understood how much time a release took, right? Then, here comes the great improvement!
It might seems stupid to say it, even more considering how much it took me to just make one release, but writing a (huge) script to handle the whole release allowed me to earn A LOT of time. You can find it here: gtk-rs/release.
Now you might wonder why I didn't do it ages ago, right? Well, because writing this script was really long and painful (I mean, testing a release of 26 crates...). It's now running correctly and a release can be done in less than an hour.
It now does everything on its own:
In the future, I think I'll add tags for repositories as well. Not sure if it's really necessary but people might be interested, so why not?
gtk-rscode> a single repository?
Since I wrote this blog post, I decided to answer this question at the same time. Enjoy! :)
So "Why not make
gtk-rs a single repository?". I had this question a lot. Funny fact: the
gtk-rs was a single repository when we started. We splitted all the crates into their own repository when we created the organization. So why did we change?
For multiple reasons:
From this point, the first issue we had to fix was the tests. Yes, testing multiple repositories to see if an update from one repository didn't break another one was vital. Even now, it's still incomplete but we made improvements.
Apart from the previous reason, we didn't see any other one which would make us want to go back to one repository. The release would still be horrible and the repository would be way too huge and horrible to manage.
As you can see, a
gtk-rs release is quite exhausting. It got better, but a lot of work remain to be done.
However, despite all this, I really like what we did with
gtk-rs and I will never thank enough the people who made it what it is now. Thank you! :)
Previous articleNew rustdoc rendering common errors
Next articleLittle tour of multiple iterators implementation in Rust