Choosing a strategy for changing nixpkgs versions about rails-nix HOT 4 CLOSED

OK, I think the way you described makes the most sense. For now, we can start simple and just use whatever version is on the builders.

SLA feels far off - for now I think we just want to have a rollback guarantee. That will soon already be available at the deployed image level. So as long as we can ensure busted builds can also be rolled back, we'll be good for a while. And Nix already guarantees this.

from rails-nix.

Also, you're right about all the Docker points. I wasn't putting down Nix here, just thinking out loud about what challenges we may face if we're entering the nix space as a code/cache maintainer. Certainly a lower surface area than 'Random Docker images maintaner' :)

from rails-nix.

What's a good strategy for deciding when to move the main pin forward? Is there already a best practice out there?

Yes, updating "ASAP" if possible it the best way to keep on top of security issues and bug fixes. Though this has to be done in a way that can be somewhat verifiable. Ideally enough automated testing to cover most scenarios.

So there are benefits to frequently moving the pin. But it will be impossible to cover all the possible issues that may pop up.

I'm noting here that if we compare to some Docker image build practices, using apt-get update somewhere in that image build is likely just as problematic.

But with that said, end-user projects don't have to be updated in sync with your own updates. So they still would have the ability to revert to a previous version if it causes unforeseen consequences. Which is not easy to do with a "self-updating layer".

How should we manage versioning of our Nix builder code and nixpkgs?

That's a good question. I don't think there's a unique good answer. Though with your description of the problem, I think you do have a good understanding of the problem space.

The builder infra could be released with a branching pattern. Imagine releases are made on a calendar base.

(letters represent abstracted Nixpkgs revisions)
fly-base 2022.03
    - 2022.03.aaaaa
    - 2022.03.bbbbb
    - ...
    - 2022.03.ggggg
    - 2022.03.hhhhh
fly-base 2022.05
    - 2022.05.ggggg
    - 2022.05.hhhhh
    - ...
    - 2022.05.ooooo
    - 2022.05.ppppp

Where there could be an overlap in Nixpkgs revision used for two distinct "versions" of the builders. Nothing forces you to do entirely linear releases. Though maintaining some versions in parallel comes at the cost of having to maintain these.

It also depends on what kind of SLA you want to provide to end-users.

from rails-nix.

One concern is that newer versions of nixpkgs could break our module implementation, as we're seeing right now. So we should setup CI on nix-base to ensure the modules load correctly as we move forward.

Closing this for now in favor of more specific issues.

from rails-nix.