Uploaded February 2023 | Updated September 2026, 2 weeks ago
A few videos ago, we modified our README to use a relative link instead of an absolute link to another file in the repo.
In this case we go the other direction and double-down on using an absolute link. There is a time for every purpose under heaven, and in this case we want to gather stones together.
The gemspec for the project and the entry on RubyGems explicitly link to the master branch version of the CHANGELOG. Because the CHANGELOG could exist in various states on different branches, it can introduce ambiguity as to which is the source of truth and become a tedious administrative chore to maintain.
In order to have a clear authority as to which CHANGELOG is the authority, we update the CHANGELOG files on our legacy branches to explicitly point to the master branch. We even add in an image that pays homage to the iconic scenes in Super Mario Brothers where you complete a castle level and are greeted by a citizen of the Mushroom Kingdom who informs you that the princess is in another castle.
We use the GitHub Markdown editor to draft our new pointer to the master CHANGELOG, and then check out and paste in the contents to each legacy branch.
After pushing to the legacy branches and verifying that the intended changes are in place, I hem and haw about whether to update the master branch version now or not. Ultimately, we defer that CHANGELOG update for a couple more videos until we start determining which changes to to each branch.
This video covers:
00:00:12 Introduction
00:01:52 Demonstrate variance in CHANGELOG files across the various stable branches
00:02:26 Show how the gemspec and RubyGems refer explicitly to the master branch CHANGELOG
00:03:45 Draft a Markdown replacement for the CHANGELOG on legacy branches that points to the master CHANGELOG
00:05:51 Make change on 0-1-x branch
00:08:10 Make change on 0-2-x branch
00:10:02 Make change on 0-3-x branch
00:11:15 Make change on 0-4-x branch
00:12:25 Go to GitHub Actions and ensure all the builds passed.
00:12:50 Validate changes on all the legacy branches
00:13:35 Indecision about whether to update the master CHANGELOG now or not, ultimately decide to defer it to another video
00:15:09 Close issue and update backlog
#ruby #rubygems #codecast #screencast #NerdDice #DnD #roleplaying #softwaredevelopment #github #opensource #dice #documentation #changelog #mario #supermariobrothers #ourprincessisinanothercastle
See other related StatelessCode videos:
- Create a RubyGem 90: Fix README to Use Relative Links Instead of Absolute Links youtu.be/fHirL25vP-8
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.
A few videos ago, we modified our README to use a relative link instead of an absolute link to another file in the repo.
In this case we go the other direction and double-down on using an absolute link. There is a time for every purpose under heaven, and in this case we want to gather stones together.
The gemspec for the project and the entry on RubyGems explicitly link to the master branch version of the CHANGELOG. Because the CHANGELOG could exist in various states on different branches, it can introduce ambiguity as to which is the source of truth and become a tedious administrative chore to maintain.
In order to have a clear authority as to which CHANGELOG is the authority, we update the CHANGELOG files on our legacy branches to explicitly point to the master branch. We even add in an image that pays homage to the iconic scenes in Super Mario Brothers where you complete a castle level and are greeted by a citizen of the Mushroom Kingdom who informs you that the princess is in another castle.
We use the GitHub Markdown editor to draft our new pointer to the master CHANGELOG, and then check out and paste in the contents to each legacy branch.
After pushing to the legacy branches and verifying that the intended changes are in place, I hem and haw about whether to update the master branch version now or not. Ultimately, we defer that CHANGELOG update for a couple more videos until we start determining which changes to to each branch.
This video covers:
00:00:12 Introduction
00:01:52 Demonstrate variance in CHANGELOG files across the various stable branches
00:02:26 Show how the gemspec and RubyGems refer explicitly to the master branch CHANGELOG
00:03:45 Draft a Markdown replacement for the CHANGELOG on legacy branches that points to the master CHANGELOG
00:05:51 Make change on 0-1-x branch
00:08:10 Make change on 0-2-x branch
00:10:02 Make change on 0-3-x branch
00:11:15 Make change on 0-4-x branch
00:12:25 Go to GitHub Actions and ensure all the builds passed.
00:12:50 Validate changes on all the legacy branches
00:13:35 Indecision about whether to update the master CHANGELOG now or not, ultimately decide to defer it to another video
00:15:09 Close issue and update backlog
#ruby #rubygems #codecast #screencast #NerdDice #DnD #roleplaying #softwaredevelopment #github #opensource #dice #documentation #changelog #mario #supermariobrothers #ourprincessisinanothercastle
See other related StatelessCode videos:
- Create a RubyGem 90: Fix README to Use Relative Links Instead of Absolute Links youtu.be/fHirL25vP-8
This video is CC0 - No rights reserved. (YouTube doesn't allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of "intellectual property". Copying is not stealing.





![Create a RubyGem 98: Replace the Expired Gem Certificate
Okay I messed up, big time. The signing certificate for our gem expired over a year ago. When you add a cert to your gem, youre making a contract with your consumers that you will have a current signed version of your gem available at all times.
With an expired cert, a HighSecurity or even MediumSecurity install will fail. We need to rectify this. The process we use to update the gem certificate
* Move the old cert to an archive directory
* Un-trust the old cert with `gem cert remove [path_to_cert]`
* Generate the new cert from the ~/.ssh directory of the local machine using the command:
`gem cert build [email in gemspec]`
* Change permission for the private key to 0600
* Copy the PUBLIC certificate to the new directory with the command
`cp ~/.ssh/gem-public_cert.pem certs/[RubyGems user name].pem from the gems root directory
* Trust the new cert with `gem cert add certs/[RubyGems user name].pem` from the root directory of the gem
* Test a build version of the gem with `gem build nerd_dice.gemspec`
* Install the built version of the gem with the command
`gem install ./nerd_dice-0.5.0.gem -P HighSecurity` (replace with built version in the future)
* Uninstall the test version of the gem with the command
`gem uninstall nerd_dice -v 0.5.0` (replace as appropriate)
In this video, the need to explicitly remove the expired cert before adding the new one gives us some trouble, but we figure it out and now our users will be able to install with high security again once we release.
This video covers:
00:00:12 Introduction
00:01:14 Demonstrate the problem
00:03:08 Archive the expired certificate and key
00:04:48 Generate the new cert and private key
00:06:41 Copy the new cert to the certs directory of the gem
00:08:38 Build the gem and test that it can be installed with HighSecurity, fails
00:10:49 Troubleshoot install failure. Solution is to remove the old cert before adding the new one
00:15:06 Test install with high security successful; uninstall test version
00:15:49 Commit the new certificate
00:16:34 Update the SECURITY.md file with new end-of-life date for other versions and amend commit to include change
00:18:54 Push to the remote, open pull request, ensure process for updating the certificate is noted in a comment in the issue
00:21:01 Merge pull request and update backlog
#ruby #rubygems #codecast #screencast #NerdDice #DnD #roleplaying #softwaredevelopment #github #opensource #dice #tlm #certificatemanagement #expiredcert
See other related StatelessCode videos:
- Create a RubyGem 06: Release the Gem! https://youtu.be/4ihGTcy9jtI
Resources that we relied upon for this solution:
- Publishing your gem RubyGems.org https://guides.rubygems.org/publishing
- Security guide RubyGems.org https://guides.rubygems.org/security
This video is CC0 - No rights reserved. (YouTube doesnt allow this option when publishing.) All code is released under the UNLICENSE. Stateless Code denies the concept of intellectual property. Copying is not stealing. Create a RubyGem 98: Replace the Expired Gem Certificate](https://i.ytimg.com/vi/TP1cReJgSro/mqdefault.jpg)




