Hi, Maxim Cournoyer <[email protected]> writes: > > The release branch would accumulate a few commits, which would later be > _merged_ into master at some points (_not_ rebased, to avoid rewriting > them since the release tag would have been placed on a commit of that > branch, which shouldn't change, e.g. for 'git describe' to print > something sensical).
I think this doesn't do it justice. We would *need* to make it a merge afterwards, not primarily because output of a command would be nonsensical. We primarily *need* to do that because people using the release wouldn't be able to pull otherwise with the default arguments. They would get the message that they aren't upgrading and they need to --allow-downgrades in case they agree to downgrade. This would probably lead to a lot of confusion, because the people are trying to upgrade, not downgrade. And they in fact would be upgrading, it's just that Guix checks that by the commit relations and there would be none. This would happen for pull and for system reconfigure. And it definitely poses a serious usability problem for newcomers. So guix describe printing something nonsencial would be the least of the issues, I believe. Anyway lately I have been thinking about the importance of the master-next branch. This branch allows Guix to still progress. People could even switch to master-next for the time being as the branch to pull for, and since most of the people who would switch would understand what it means, they would also not be so much surprised about the need to run --allow-downgrades once master-next is rebased onto master after the release. So this allows us to 1. pretty much not stagnate Guix, 2. prevent merges that, as Andreas pointed out, are currently not an accepted way for putting commits onto master. Rutherther
