Hey Simon,
Simon Josefsson <[email protected]> writes: > Rutherther <[email protected]> writes: > >> This is solved in the Guix System installer by bumping the guix package >> and making the system from commit that bumped it to 1.5.0rc1 rather than >> from commit tagged as 1.5.0rc1 directly. But on foreign distros, you're >> right it will end up like this. It's always better to first pull. >> >> This was the same case with 1.4.0. Maybe we could try doing something >> about it if it's unexpected for users, but I don't know what. The only >> possibility that comes to my mind to solve this would be to solve it >> similarly to the Guix System installer. We would distribute the binary >> tarballs with guix package from commit that has the package bumped. That >> would mean the tarballs aren't made from the tagged release commit >> itself, though. However, that would mean that `guix --version` would >> tell you it's something like `1.5.0rc1-1.<part of hash>` and that seems >> unexpected to me. > > I think the 'v1.5.0rc1' tag should be for when that version of guix is > made available. > > That is, I think the tag should have been on commit > d339785a0fbd8f13930082a4fa7a73b6685630fd rather than > 2d4ed08662714ea46cfe0b41ca195d1ef845fd1b -- compare info from > 'git log --format=oneline': I don't think we can do that, then we would be saying the guix package is 1.5.0rc1, but it actually wasn't, because there was no tag to say so. That doesn't seem right to me. We need to have a uniquely determined commit that is 1.5.0rc1. If we did what you suggest, it seems to me there is a possibility to treat either of the two commits as 1.5.0rc1, which seems strange. This is because with the Guix package we're saying 1.5.0rc1 is at N, while with tag we're saying it's at N+1. > > d339785a0fbd8f13930082a4fa7a73b6685630fd (origin/version-1.5.0, > version-1.5.0) g > nu: guix: Update to 1.5.0rc1. > ... > 2d4ed08662714ea46cfe0b41ca195d1ef845fd1b (tag: v1.5.0rc1) etc: release: > Switch to Guile declaration of artifacts. > > Yes this is different from what has been done traditionally, so > disagreeing with my suggestion is fine. Yes, it is different, check for example the 1.4.0 version where it's done like this. Some previous versions were different, where it was actually two commits that were updating the Guix package. That's not needed anymore as the Guix System images now use (current-guix) to overcome issues that would be previously encountered by doing just one bump. However as can be seen from earlier e-mails, this can still be a problem on foreign distros. And maybe prior to that it was even more different, I didn't check that far. > > What purpose does a git tag on 2d4ed08662714ea46cfe0b41ca195d1ef845fd1b > serve? Is it consumed by anything? Other than the human doing the > d339785a0fbd8f13930082a4fa7a73b6685630fd commit? It's not by human, the guix package is updated by `make update-guix-package`, also it's used by `make dist` that's done as part of the release to get the source tarball. This is done on the tagged commit and autotools will make the name according to the tag, being 1.5.0rc1. See the `prepare-release` and `release` targets in Makefile.am. > > If the tag on the first commit really is useful, how about a two-stage > release process like this: > > 1) 'git tag -s -m foo v1.5.0rc1-guix' - similar to the tag on > 2d4ed08662714ea46cfe0b41ca195d1ef845fd1b. Or make the tag > namespace-separated as 'guix/v1.5.0rc1'? > > 2) Merge the guix update as done in commit > d339785a0fbd8f13930082a4fa7a73b6685630fd and tag that as 'git tag -s -m > bar v1.5.0rc1'. Sorry I don't really understand this. Still it's not clear what commit the dist should be made from or why we would say that guix is 1.5.0rc1 when it's not yet 1.5.0rc1. Rutherther > > Does this break anything? > > /Simon
