Change:
<del> { stdenv, buildGoPackage, fetchFromGitHub }: </del> <ins> { stdenv, buildGoModule, fetchFromGitHub }: </ins> <del> buildGoPackage rec { </del> <ins> buildGoModule rec { </ins> pname = "gotop"; <del> version = "3.0.0"; goPackagePath = "github.com/cjbassi/gotop"; </del> <ins> version = "3.5.0"; </ins> src = fetchFromGitHub { <del> owner = "cjbassi"; </del> <ins> owner = "xxxserxxx"; </ins> repo = pname; <del> rev = version; sha256 = "1kndj5qjaqgizjakh642fay2i0i1jmfjlk1p01gnjbh2b0yzvj1r"; </del> <ins> rev = "v${version}"; sha256 = "01a2y2604dh2zfy5f2fxr306id0fbq0df91fpz2m8w7rpaszd6xr"; </ins> }; <ins> modSha256 = "1gbpxq2vyshln97gij5y9qsjyf3mkwfqwwhikc0cck3mnwiv87dd"; </ins> meta = with stdenv.lib; { description = "A terminal based graphical activity monitor inspired by gtop and vtop"; <del> homepage = https://github.com/cjbassi/gotop; </del> <ins> homepage = "https://github.com/xxxserxxx/gotop"; </ins> license = licenses.agpl3; maintainers = [ maintainers.magnetophon ]; platforms = platforms.unix;

Discussion:
Project description gotop is already a Nix package. The upstream maintainer is no longer maintaining the package, and a new repository and maintainer (myself) is developing and maintaining the software. I'm requesting that the Nix package point at the new upstream repository, and version bump to the latest release (3.3.2). The original repository README includes an out-of-maintenance notice as well as a link to the new repository. Metadata homepage URL: source URL: license: Same as before, AGPL 3.0 platforms: Windows, Darwin, FreeBSD 386 & amd64; Linux 386, amd64, ARM 5-7, ARM64 I gave updating the package myself a shot but eventually got stuck with ; while generated and referenced, is ignoring it so I'm doing something wrong. It's probably better if the package maintainer manage this.
That was quick; thank you. Did I follow the right process, or is there another way of flagging packages as needing update? How do I ensure that only released versions are picked up? v3.3.2 is the version that's been released; v3.4.5 is in soak test. It should be fine, but it's a beta. Is this an issue, and if so, what can I do to make the right thing happen? Thanks again. I appreciate your efforts.
Adding a comment in the package file about how to determine the correct release version would help with this. (As would adopting a less confusing versioning policy )
I thought the comment "and version bump to the latest release (3.3.2)" would be sufficient. Sorry about the confusion. Versioning follows Semver. The software has a release process, and binary builds don't go out and package definitions (AUR, Homebrew, deb and rpm) are not pushed until I click the "Release" button. As I mentioned, I'm newly assuming maintainership and am still setting things up (and dealing with several distribution channels). Once the CI is solid, I won't push tags that aren't ready for release as that'll trigger the release process. Until then, (and it may take a couple more tags) I'd like to be able to explicitly identify the "released" version. I did not contribute to the package file.

I tried, but Nix defeated me. How do I add a comment about determining the correct release version? I'm reluctant to submit a pull request, as I can't get the Nix package to work with my repo, and my changes were ineffective.
I just released a (minor revision) bug-fix tagged "v3.5.1". It is not the head of master, but it is properly tagged. I am happy to update the hashes in the and issue a pull request, but I keep getting stuck. Right now, it's complaining about being unable to verify hashes for derivations (.drv) it's building, and I can't figure out where it's getting the hashes or the correct process for updating them; the hashes that it's complaining about don't appear in the . In any case, it's obviously not a simple case of updating a version and hash in a package definition and I'm missing steps. Shall I file new tickets for every release, update this one, or do I need to become a Nix packaging expert to help?
I released v4.0.0 of gotop. It's tagged as such. I'm not sure how all distributions manage this sort of thing so here are some caveats: command-line arguments changed in a way that is not backwards compatible. It's equivalent to an API incompatability. compilation should change to include building in the version and build date into the executable; I'm no longer manually updating the version string in the source code. It might look like this: We build with on Arch because Arch complains otherwise about relocatable security issues, but whatever is standard for Nix should be used here. should be taken from the package version -- gotop versions are prefixed with a e.g. . Thank you
I just released v4.1.0 of gotop. It's tagged as such, and is on master. As usual, the contains a non-developer-understandable (I hope) list of changes. Thanks!
I just published .