In this post I will talk about release management with MySQL as example. Release management has to do with what to put in a release, how often to do a release, how to long to support a release and how to number or name the releases. The early years Today software is almost exclusively delivered over the internet, but this didn’t use to be the case. Software used to be delivered in a box that you had to buy at a physical store. These were often shrink wrapped and forced you to agree with the EULA by opening the box. The box then contained floppies, CD’s, DVD’s or any other suitable medium. There were multiple reasons why physical media were used, even when the internet arrived. One of the main limitations was bandwidth, this is also why FreeBSD, Linux, etc were sold on physical media. And one of the other reasons was that online payment wasn’t as ubiquitous as it is today. Then there were also ways of copy protection that relied on physical media and/or dongles. For operating systems...

This story starts with a pull request for go-mysql to allow setting the collation in auth handshake that I was reviewing. The reason why the author wanted to do this is to speedup the connection setup as he has a latency sensitive application and a lot of connection setups and tear downs. While looking at this I noticed that the collation would be stored in a single byte. However the list of supported collations shows collations with an ID that’s more than 255. mysql> SELECT MIN(ID),MAX(ID) FROM information_schema.collations; +---------+---------+ | MIN(ID) | MAX(ID) | +---------+---------+ | 1 | 323 | +---------+---------+ 1 row in set (0.00 sec) The protocol documentation for Protocol::HandshakeResponse41 says that the value sent here is only the lower 8-bits. So I was wondering how do other connectors send this to the server? Are the other 8-bits sent elsewhere in the protocol? So I used MySQL Connector/Python to try this out. import mysql.connector c = mysq...

The MySQL Protocol is the network protocol that is used between a MySQL server and a client. This is called the “classic” protocol as there is now a newer protobuf based protocol called X Protocol . However the “classic” protocol is used by many database drivers, applications, etc. and also by MySQL Replication. The MySQL Protocol has the option to compress network traffic. Most client libraries don’t enable this by default as this increases CPU usage. Some history Initially this was added in MySQL 3.22 (based on historical release notes) and was based on zlib . Then in MySQL 8.0.18 a second compression algorithm, Zstandard , was added based on a contribution by Facebook . So zlib has been there basically forever and Zstandard support is new-ish (8.0.18 was released in October 2019). Why you might want to use compression. There are multiple usecases that are often mentioned when talking about the compressed protocol. The first one is slow connections. This could, for example, ...