How are releases tagged? #40
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
After trying to pin my flake to 2.91.1, I get the error below:
Before the release, I was pinning Lix directly to
0dda988746
because I also couldn't build the system with 2.91.0; Now that 2.91.1 is out, I am pinning Lix to81d9ff97c9
because that's the commit that fixes my build failure.I'm a bit lost to where
81d9ff97c9
ended up, it's been authored 3 weeks ago, it's been in main for some time now, and 2.91.1 has been tagged less than a day ago, yet it doesn't include this commit.I'm not sure if these release branches are meant to be cut from main, or if fixes were meant to be cherry-picked, but the end result is that I cannot pin my flake to a release and instead I have to look for versions that build.
Is there anything I can do here to help out? I'd be happy to run my home config against every single commit if that provides some usable signal, but what I'd like to have in the end is a flake pinned to either a "latest stable" (#39) or manually pinning to a version & updating with renovate. But for that I'd like to make sure that my config builds (provided I make any necessary changes on my end).
the answer to your question is i fucked up some cherry picks. sorry.
what I'm going to do about it is add more flake checks such that it's harder to screw up module releases. i did run the tests. they were inadequate. but yeah :/
release engineering only makes me want to cry, especially when people write issues assuming I'm incompetent rather than overworked and burned out by maintaining fragile code that breaks due to external influence. the reason that the 2.91 branch got into a rather questionable git state is that i made an attempt to bring it in line with the main version and most likely screwed up a merge conflict while doing so and then the tests were inadequate.
alright there is a 2.91.1-1 tag. i will open a new issue to fix the validation since clearly we are not doing a good enough job (and what we have already confuses users).
Thank you so much @jade, and for the record I meant in no way to imply incopetence. I understand that in general life is happening, and maintaining open source software might not always be the top priority, so know that I'm thankful for your work on the project. I really thought the missed commit was intentional somehow and not a mistake :)
🍦