For us a release branch is created when we've accumulated enough serious bug fixes in the main branch but the main branch isn't ready to make into a release.

We then branch the main branch from the last .0 release, cherry pick the important bug fixes, test and release a .1 release.

Nice write up, thank you. We use trunk based development in rclone but we do make release branches. These are only allowed to have fixes cherry picked from the main branch though which helps keeps the complexity down rather than having a life of their own.

Well done Simon 😀

I'd have liked to see in the FAQ how long the uploaded data is kept for.

I hope it goes well.

S3 buckets can't have _ in because they have to be DNS safe and you can't have _ in DNS names. Other than that, no idea!

I can live without the track point but not the 3 buttons!

I think I'd take became a talk as a win!

I haven't had quite enough time or energy to make any tasks this year, so respect for yours 😁

Gah, I did exactly the same thing recently. I reverted the commit then committed it with a sensible message.

That is really terrible UI by GitHub and I'm not using those private security branches again!

Google photos API and rate limits are both awful. It's almost as if they don't really want 3rd party tools interacting with Google photos.

Yes had a few of those :-(

I wish dependabot wrote better commit messages rather than updated version x to y without a reason.

Something with links to the vulnerability report, putting the CVE number in the title, etc.

Just checked the code for `rclone serve sftp` - I think we are doing this correctly storing anything we concluded from the key in the Extensions map then reading it back later when it is authed.

Whew!

Its for a game to be used by children so will get some force applied to it when they plug it in to charge.

Perfboard wings might work - nice idea - thank you.

Or maybe I'll just glue it onto the case in the time honored tradition of bodgers everywhere ;-)