4 ms·

For open source code, I think the concern is practical: bit rot is real, and libraries with no recent updates are more likely to have suffered bit rot. It's not

For open source code, I think the concern is practical: bit rot is real, and libraries with no recent updates are more likely to have suffered bit rot. It's not that a library can't be finished, but that the world in which it lives never stops moving. It can be a bigger or smaller problem depending on the ecosystem. Old C89 libraries have a good chance of still working, because the ecosystem isn't moving so much any more. Old C# libraries almost definitely don't, because the ecosystem is moving quickly.

forgotmypw17 4y ago
Perhaps the solution is a monthly "NOOP" release?
- twicetwice 4y ago
  maybe commit to a log indicating that the test suite has run correctly as of <today's date>?this assumes you have a useful test suite but also at least indicates that you're still paying attention & trying to ensure your library works
  - forgotmypw17 4y ago
    Great idea!
  - svieira 4y ago
    quid custos ipsos custodiet still applies. The fact that your test suite ran in Esolang v27.8 successfully doesn't mean what you-the-consumer want it to mean if the last supported version of Esolang is v96.2. It just means someone down-stack of you is committed to backwards compatibility.
    - travisjungroth 4y ago
      That future version won’t be on the supported versions list anyway.
      - forgotmypw17 4y ago
        I think this varies by project. I personally support every version of my projects. My goal is not to minimize the effort to myself but to facilitate the use of my software.
        travisjungroth 4y ago
        I meant the new version of Esolang, v96.2, wouldn’t be explicitly supported by your project.
        forgotmypw17 4y ago
        Ah, also a good point.
- budoso 4y ago
  Agreed but this definitely isn’t in the interest of library maintainers. If they did so it’d mean they are acknowledging all the currently open issues and deciding to do nothing, which would sometimes cause backlash.
  - bliteben 4y ago
    I mean most projects just auto close all issues now. Dunno where this desire to have 0 open issues came from. Seems like in the past projects would mark the issue as unconfirmed and ignore it, now they all want to close the thread and not allow further comments. Almost as if someone is going to judge their open source project negatively for having open issues, which if that has ever happened that person is more insane than the devs practicing this.
- ep103 4y ago
  I would assume a noop is automated, and the library is no longer maintained. If, however, I saw a statement at the top of the README that said: "Update as of 2 months ago: We believe this project to be complete. We are not adding new features at this time, but if you see any issues, please open a ticket, as this project is still under active development as needed" then I would feel very confident.
  - forgotmypw17 4y ago
    Thanks, that's a good point.
ryandrake 4y ago
Bits don't rot--vendors break things. If my code built with yesterday's SDK and ran on yesterday's OS, and it doesn't for today's, that's not some supernatural phenomenon where digital media rots away--let's clearly blame who's causing it: SDK and OS vendors making changes that break backward compatibility and dump the maintenance burden on developers. The term "bit rot" is an attempt to shift the blame away from those who are causing the rot in the first place. Whether or not it's good to have a moving ecosystem is another story, but I request we not use the term "bit rot" when we mean "vendors breaking compatibility."

forgotmypw17 4y ago

Perhaps the solution is a monthly "NOOP" release?

twicetwice 4y ago
maybe commit to a log indicating that the test suite has run correctly as of <today's date>?this assumes you have a useful test suite but also at least indicates that you're still paying attention & trying to ensure your library works
- forgotmypw17 4y ago
  Great idea!
- svieira 4y ago
  quid custos ipsos custodiet still applies. The fact that your test suite ran in Esolang v27.8 successfully doesn't mean what you-the-consumer want it to mean if the last supported version of Esolang is v96.2. It just means someone down-stack of you is committed to backwards compatibility.
  - travisjungroth 4y ago
    That future version won’t be on the supported versions list anyway.
    - forgotmypw17 4y ago
      I think this varies by project. I personally support every version of my projects. My goal is not to minimize the effort to myself but to facilitate the use of my software.
      - travisjungroth 4y ago
        I meant the new version of Esolang, v96.2, wouldn’t be explicitly supported by your project.
        forgotmypw17 4y ago
        Ah, also a good point.
budoso 4y ago
Agreed but this definitely isn’t in the interest of library maintainers. If they did so it’d mean they are acknowledging all the currently open issues and deciding to do nothing, which would sometimes cause backlash.
- bliteben 4y ago
  I mean most projects just auto close all issues now. Dunno where this desire to have 0 open issues came from. Seems like in the past projects would mark the issue as unconfirmed and ignore it, now they all want to close the thread and not allow further comments. Almost as if someone is going to judge their open source project negatively for having open issues, which if that has ever happened that person is more insane than the devs practicing this.
ep103 4y ago
I would assume a noop is automated, and the library is no longer maintained. If, however, I saw a statement at the top of the README that said: "Update as of 2 months ago: We believe this project to be complete. We are not adding new features at this time, but if you see any issues, please open a ticket, as this project is still under active development as needed" then I would feel very confident.
- forgotmypw17 4y ago
  Thanks, that's a good point.

ryandrake 4y ago

Bits don't rot--vendors break things. If my code built with yesterday's SDK and ran on yesterday's OS, and it doesn't for today's, that's not some supernatural phenomenon where digital media rots away--let's clearly blame who's causing it: SDK and OS vendors making changes that break backward compatibility and dump the maintenance burden on developers. The term "bit rot" is an attempt to shift the blame away from those who are causing the rot in the first place. Whether or not it's good to have a moving ecosystem is another story, but I request we not use the term "bit rot" when we mean "vendors breaking compatibility."