Adapted nextversion.sh to support major.minor.patch version scheme

[buhl]

As discussed in #271 I adapted nextversion.sh and the Makefile to work with semver and git describe

[buhl]

How does this work? Do I just update my branch with the suggestions and the pull request will update automatically or do we need to close this one and I'll make a new one?

[wilhelmy]

Yep, if you push to the branch it'll show up in here. Someone who were to review your changes can then decide whether they want to squash all commits into one commit and put that on master, do a merge commit against master or rebase all commits onto master to avoid having a merge commit cluttering the git history.

[buhl]

Is the snapshot target in the Makefile still in use? If so I will adapt it to work with the newversion.sh as well. I am not sure it's working right now...

[wilhelmy]

Regarding "make snapshot", I used to have relatively strong opinions that releases should come in pre-packaged tarballs signed by the maintainer, but I think we've switched to a plain tag-based distribution method with 4.0... I'm not sure if you can verify the signature on those tags without cloning the repository, though. I assume tarballs downloaded from GitHub do at least always have the same checksum.

[buhl]

Regarding "make snapshot", I used to have relatively strong opinions that releases should come in pre-packaged tarballs signed by the maintainer, but I think we've switched to a plain tag-based distribution method with 4.0... I'm not sure if you can verify the signature on those tags without cloning the repository, though. I assume tarballs downloaded from GitHub do at least always have the same checksum.

Hmm, a (very) quick tour around the internet only came up with descriptions of manual signing of tarbals. This one was referred to quite often. I don't have any experience with CI/CD tools like travis, but maybe tools like that can help?

[buhl]

There might be some info related to signed releases through travis here: https://github.com/Shingyx/travis-signed-apk-release-example

[wilhelmy]

I'm not a travis expert but I'll gladly steal anything ingenious that I can take away :)

[wilhelmy]

Apparently it's possible to attach binary files to releases drafted using release-drafter. I think it would be possible to attach tarballs and gpg signatures there.

[buhl]

Apparently it's possible to attach binary files to releases drafted using release-drafter. I think it would be possible to attach tarballs and gpg signatures there.

Does this mean all we might have to do is tag commit and travis will then run off and make the release and sign the files? If that's the case I can remove the snapshot target from the Makefile

[wilhelmy]

No, I was talking manual upload because I live in the 90s

[raboof]

I used to have relatively strong opinions that releases should come in pre-packaged tarballs signed by the maintainer, but I think we've switched to a plain tag-based distribution method with 4.0

I'm not sure signed tarballs still have value: for releases, signing the tag should be equivalent security-wise. Having a tarball separate from the git repo itself is just duplication that has the potential to be out of sync and actually hide security problems... so I would be OK with removing the snapshot target

[wilhelmy]

The problem is, the way distribution packages work on pretty much all distributions, the build tools expect a tarball, which won't be signed even if the release is signed. Probably all hope is lost anyway, nevermind me, I'm probably gonna go curl|sudo bash some things later this year.

[raboof]

the way distribution packages work on pretty much all distributions, the build tools expect a tarball

Debian and Slack are happy to get the github-provided tarball (https://manpages.debian.org/stretch/devscripts/uscan.1.en.html#github.com, https://slackbuilds.org/repository/14.2/desktop/notion/), NixOS and Arch get the git tag itself (https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/window-managers/notion/default.nix#L12, https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/notion#n50), so that doesn't seem to be a big limitation at this point.

I'm probably gonna go curl|sudo bash some things later this year.

I agree that is not great, but TBQH downloading a tarball, checking the signature (against what?) and running 'sudo make' is not a lot better really... Going offtopic here, but I would love it to be easier to compartimentalize your system more. With namespaces I think a lot of the groundwork that would make that possible is already there, but I feel 'docker' isn't really the answer yet from a usability point of view.

The convenience of NixOS's 'nix-shell' combined with the isolation provided by linux namespaces wrapped into something resembling QubesOS seems really compelling to me ;)

[buhl]

So, I think this PR is as ready for a review. it says the checks are not completed but if you go to travis they are done. I think we should merge this issue and take the travis talk to a new issue, what do you guys thing?

[raboof]

take the travis talk to a new issue

I think that just 'sometimes happens', not sure if we can do anything about it.

[raboof]

Thanks, I learned a few things :D