I’m using a couple of packages from unstable, but one of them isn’t the software’s newest version, which is necessary for it’s functionality.
Is it inadvisable to use an overlay to always use the ‘latest’ github version of a piece of software? or should I first learn how to test the software’s latest release and make a pull request to nixos? I’ve done it once before with some very generous hand-holding, but I’ve since forgotten the process.
Overlays or not don’t change this.
“latest” is rather unspecific, and for now sounds like “most recent release”. But nix doesn’t understand version strings or whatever. The best you could get is to use a branch and follow that. Either by using flakes inputs, niv or maybe impure builtins.fetch* without a hash.
Though the pure variants are of course prefered.
I was referring to this:
You can share a link to the latest release for a repository by adding
releases/latestto the end of a repository’s URL. For example, the URL for the latest release ofocto-org/octo-repoishttps://github.com/octo-org/octo-repo/releases/latest.
from here.
Is that not something that I can use in nix?
If GH supports this, and it is sufficient for your usecase 
Though as we have changing content behind a fixed URL, you need an impure fetcher here.
Alright, I think what I’m understanding is that this is kinda the opposite of how nixos is supposed to work lol. So now I gotta figure out how to test and update the unstable branch to the latest version, right? where should I start.
If this is the case, you should open an issue on that because if software is outdated to the point where it does not reasonably function, it should be updated. We can even update software past its latest official release if there is good reason to do so.
If this was just how the regular Nixpkgs package worked, that’d be best for everyone involved.
Clone the Nixpkgs repo and update the package by editing its expressions and changing the version and hash. Then attempt to build the package locally and test whether it works as expected. Once you’ve done that you can commit your changes according to the commit message guidelines, push it to your fork and then create a PR where you ideally describe how much you tested the package.
Then wait for reviews and respond to them.