4 ms·

Do you keep multiple branches of your programs, including one where you do not add new features but only bugfixes and such security updates? (And I am skeptica

Do you keep multiple branches of your programs, including one where you do not add new features but only bugfixes and such security updates? (And I am skeptical of claims that leaf developers can keep up with the traffic of security updates)

sunshowers 2y ago
I build my programs to be append-only, such that users can always update to new versions with confidence. For example, I'm the primary author and maintainer of cargo-nextest [1], which is a popular alternative test runner for Rust. Through its history it has had just one regression. If I did ever release a new major version of nextest, I would definitely keep the old branch going for a while, and make noises about it going out of support within the next X months. Security updates aren't that common, at least for Rust. I get maybe 5-6 alerts a year total, and maybe 1-2 that are actually relevant. [1] https://nexte.st/ https://nexte.st/
- AshamedCaptain 2y ago
  > I build my programs to be append-only, such that users can always update to new versions with confidence. And in this wonderful world where developers are competent enough to manage this, and therefore there are no issues when libraries are updated (append-only, right?).... why do you have a problem with shared linking again? Or is this a case where you think yourself as an "above average" programmer?
  - sunshowers 2y ago
    I think the difference is that library interfaces tend to be vastly more complex than application interfaces, partly because processes form fairly natural failure domains (if my application does something wrong it exits with a non-zero code, but if my library does something wrong my entire program is suddenly corrupted.) There are also significant benefits to static linking (such as inlining and LTO) that are not relevant across process boundaries. But yes, in a sense I'm pushing the problem up the stack a bit. > is this a case where you think yourself as an "above average" programmer? I've been very lucky in life to learn from some of the best minds in the industry.

sunshowers 2y ago

I build my programs to be append-only, such that users can always update to new versions with confidence. For example, I'm the primary author and maintainer of cargo-nextest [1], which is a popular alternative test runner for Rust. Through its history it has had just one regression. If I did ever release a new major version of nextest, I would definitely keep the old branch going for a while, and make noises about it going out of support within the next X months. Security updates aren't that common, at least for Rust. I get maybe 5-6 alerts a year total, and maybe 1-2 that are actually relevant. [1] https://nexte.st/ https://nexte.st/

AshamedCaptain 2y ago
> I build my programs to be append-only, such that users can always update to new versions with confidence. And in this wonderful world where developers are competent enough to manage this, and therefore there are no issues when libraries are updated (append-only, right?).... why do you have a problem with shared linking again? Or is this a case where you think yourself as an "above average" programmer?
- sunshowers 2y ago
  I think the difference is that library interfaces tend to be vastly more complex than application interfaces, partly because processes form fairly natural failure domains (if my application does something wrong it exits with a non-zero code, but if my library does something wrong my entire program is suddenly corrupted.) There are also significant benefits to static linking (such as inlining and LTO) that are not relevant across process boundaries. But yes, in a sense I'm pushing the problem up the stack a bit. > is this a case where you think yourself as an "above average" programmer? I've been very lucky in life to learn from some of the best minds in the industry.