2.0.1 release #1949
2.0.1 release #1949
Conversation
|
Would be nice to have a release with the recent fixes. |
|
Having a release with your ssh-ng fixes would be awesome for my team. |
|
Please just cherry-pick bug fixes to the 2.0-maintenance branch and don't add release notes for bug fix releases. |
|
Hmm I think maintenance branches are likely to put us back in the position of having significant divergence between the latest release and the latest master and make it harder to get out feature releases as well. Can you explain why you prefer the maintenance model over releasing from master? |
|
It would be appropriate to release 2.1 from master, but not 2.0.1. Users should be able to count on patch releases like 2.0.1 not introducing regressions. |
|
Do you have any thoughts on how we can avoid divergence under this model? My thought is just that we should just bump to 2.1 (not necessarily released, just in the version file) as soon as we make a change justifying that. |
|
@edolstra (and rest of @NixOS/nix-core ) can you join the nix-core ml? I'd like to move this discussion there. |
|
Doing more frequent major releases in no way removes the need for a maintenance branch, especially given the existence of stable NixOS branches, since it would be irresponsible to apply major Nix upgrades in a stable NixOS branch (it should only receive bug fixes). |
|
@shlevy I don't think these ended up cherry-picked into the maintenance branch. Is that right? |
|
@puffnfresh Correct, there's an ongoing discussion about Nix release process that I hope to turn into an RFC this week https://groups.google.com/forum/#!topic/nix-core/9L7jZ9W8VGc |
No description provided.