9 ms·

I keep a release TODO list and about 50% of every release, I fuck up and need to add something to the list. It's about 40 items long now (containing various ter

I keep a release TODO list and about 50% of every release, I fuck up and need to add something to the list. It's about 40 items long now (containing various terminal commands and activities), which includes making sure manual entries, documentation, the website, social media, dependencies, etc are handled correctly.

Swizec 7y ago
Sounds like a great potential SaaS offering
- z3ugma 7y ago
  Manifest.ly is designed for this workflow - https://www.manifest.ly/ https://www.manifest.ly/
PacifyFish 7y ago
What kinds of things do you need to check for that aren’t automated? Maybe I’m spoiled by our CI pipeline. I’d love to take a look at your list
- vortico 7y ago
  Here's a somewhat redacted version. `m` is my alias for `make`. - Finalize source - Legal check `LICENSE-dist.txt` - Update `CHANGELOG.md` - Bump version in `Makefile` and `Core.json` - Commit "Bump version". - Build (three OS's can be done in parallel) - `m clean` - `git pull` - Make sure you have the latest `Fundamental.zip` package in source root. - `m dist` - Manually test installer and fragile features (audio drivers, patch loading) for ~10 minutes. - `m notarize` (on Mac) - `m upload` - `git tag vX.Y.Z` - `git push --tags` - Release - Update version title and URLs in `Rack.pug` - `m upload` - At this point, normal users have access to new version. - Update server version in `config.coffee` - `m restart` - At this point, normal users will swarm to download new version. Keep an eye on server bandwidth. - Publicize - Twitter https://twitter.com/home - Facebook https://www.facebook.com/vcvrack/ - Share on group - Forum https://community.vcvrack.com/c/announcements
  - enriquto 7y ago
    this list is a very simple algorithm. Why don't you tun it into a script deploy.sh ?
    - vortico 7y ago
      No it's not.
      - enriquto 7y ago
        But it almost is, already! Half of the lines are literally shell commands. And except maybe for the legal check, the rest of the steps can also be written as shell one-liners. For example, to update the version on a README file you can "sed -i" with an appropriate replacement, and so on.
        vortico 7y ago
        Can you explain how your ./deploy.sh script forks onto three laptops (Windows/Mac/Linux) and "plays around" with the installers/build a bit to make sure it works? I obviously can't release builds that don't even run because I didn't take a few minutes to test them.
        enriquto 7y ago
        Why don't you use virtual machines?
        vortico 7y ago
        Good question. 1) A MacOS virtual machine is probably illegal. 2) I need to test the builds on all three machines, and VMs don't handle OpenGL, USB drivers (e.g. for MIDI controllers), and audio drivers very well or at all. 3) I need to have a rough idea of performance of the build. VMs affect performance by non-constant/unpredictable factors. For example, CPU performance might be 1x the speed of a bare-metal OS, but graphics performance might be 0.25x. 4) I don't know how to write a shell script on a host computer that launches Windows 10 and runs commands with an MSYS2 Mingw64 shell.
- gourlaysama 7y ago
  The Scala release checklist [1] is a good example of a release checklist with both automated and manual steps. [1]: https://github.com/scala/scala-dev/issues/645 https://github.com/scala/scala-dev/issues/645
chubot 7y ago
Every time I "fuck up", I add a few commands to a shell script, so I don't mess up the next time. Over time that has grown into over 1000 lines of shell, e.g. https://github.com/oilshell/oil/blob/master/devtools/release.sh https://github.com/oilshell/oil/blob/master/devtools/release... And this is why I'm writing a shell -- because it's good for automating things that you are otherwise too lazy to automate! I find that "semi-automation" is a good middle ground. This is where shell is better than "real" languages. You don't have to commit to writing a polished program -- you just incrementally improve things and it makes problems go away. The time you put in is saved immediately, as opposed to other languages, where you might spent 30 minutes writing something that will save you 2 minutes in the next year, which isn't necessarily worth it. If you keep a text file with a bunch of terminal commands, then you might as well chmod +x it and put #!/bin/sh on the front. That's what a shell script is! ---- Here is the output of the release process, which has tarballs, change logs, documentation, test results, benchmarks, etc. https://www.oilshell.org/release/0.7.pre5/ https://www.oilshell.org/release/0.7.pre5/ It's way to much to do by hand.
ssully 7y ago
It's so relieving to read this thread. Last year I took over management of some legacy scripts and was tasked with updating them (move from Python2 to 3, interfacing with some new APIs, etc). One of the biggest stresses I had was little fuck ups I kept doing with the releases. It was never anything huge, but every few releases I would end up taking 15-30 minutes longer then I planned, and would involve me updating the release process slightly.

Swizec 7y ago

Sounds like a great potential SaaS offering

z3ugma 7y ago
Manifest.ly is designed for this workflow - https://www.manifest.ly/ https://www.manifest.ly/

PacifyFish 7y ago

What kinds of things do you need to check for that aren’t automated? Maybe I’m spoiled by our CI pipeline. I’d love to take a look at your list

vortico 7y ago
Here's a somewhat redacted version. `m` is my alias for `make`. - Finalize source - Legal check `LICENSE-dist.txt` - Update `CHANGELOG.md` - Bump version in `Makefile` and `Core.json` - Commit "Bump version". - Build (three OS's can be done in parallel) - `m clean` - `git pull` - Make sure you have the latest `Fundamental.zip` package in source root. - `m dist` - Manually test installer and fragile features (audio drivers, patch loading) for ~10 minutes. - `m notarize` (on Mac) - `m upload` - `git tag vX.Y.Z` - `git push --tags` - Release - Update version title and URLs in `Rack.pug` - `m upload` - At this point, normal users have access to new version. - Update server version in `config.coffee` - `m restart` - At this point, normal users will swarm to download new version. Keep an eye on server bandwidth. - Publicize - Twitter https://twitter.com/home - Facebook https://www.facebook.com/vcvrack/ - Share on group - Forum https://community.vcvrack.com/c/announcements
- enriquto 7y ago
  this list is a very simple algorithm. Why don't you tun it into a script deploy.sh ?
  - vortico 7y ago
    No it's not.
    - enriquto 7y ago
      But it almost is, already! Half of the lines are literally shell commands. And except maybe for the legal check, the rest of the steps can also be written as shell one-liners. For example, to update the version on a README file you can "sed -i" with an appropriate replacement, and so on.
      - vortico 7y ago
        Can you explain how your ./deploy.sh script forks onto three laptops (Windows/Mac/Linux) and "plays around" with the installers/build a bit to make sure it works? I obviously can't release builds that don't even run because I didn't take a few minutes to test them.
        enriquto 7y ago
        Why don't you use virtual machines?
        vortico 7y ago
        Good question. 1) A MacOS virtual machine is probably illegal. 2) I need to test the builds on all three machines, and VMs don't handle OpenGL, USB drivers (e.g. for MIDI controllers), and audio drivers very well or at all. 3) I need to have a rough idea of performance of the build. VMs affect performance by non-constant/unpredictable factors. For example, CPU performance might be 1x the speed of a bare-metal OS, but graphics performance might be 0.25x. 4) I don't know how to write a shell script on a host computer that launches Windows 10 and runs commands with an MSYS2 Mingw64 shell.
gourlaysama 7y ago
The Scala release checklist [1] is a good example of a release checklist with both automated and manual steps. [1]: https://github.com/scala/scala-dev/issues/645 https://github.com/scala/scala-dev/issues/645

chubot 7y ago

Every time I "fuck up", I add a few commands to a shell script, so I don't mess up the next time. Over time that has grown into over 1000 lines of shell, e.g. https://github.com/oilshell/oil/blob/master/devtools/release.sh https://github.com/oilshell/oil/blob/master/devtools/release... And this is why I'm writing a shell -- because it's good for automating things that you are otherwise too lazy to automate! I find that "semi-automation" is a good middle ground. This is where shell is better than "real" languages. You don't have to commit to writing a polished program -- you just incrementally improve things and it makes problems go away. The time you put in is saved immediately, as opposed to other languages, where you might spent 30 minutes writing something that will save you 2 minutes in the next year, which isn't necessarily worth it. If you keep a text file with a bunch of terminal commands, then you might as well chmod +x it and put #!/bin/sh on the front. That's what a shell script is! ---- Here is the output of the release process, which has tarballs, change logs, documentation, test results, benchmarks, etc. https://www.oilshell.org/release/0.7.pre5/ https://www.oilshell.org/release/0.7.pre5/ It's way to much to do by hand.

ssully 7y ago

It's so relieving to read this thread. Last year I took over management of some legacy scripts and was tasked with updating them (move from Python2 to 3, interfacing with some new APIs, etc). One of the biggest stresses I had was little fuck ups I kept doing with the releases. It was never anything huge, but every few releases I would end up taking 15-30 minutes longer then I planned, and would involve me updating the release process slightly.