5 ms·
agreed. why optimize for the future when that optimization may directly block/slow your trajectory?
by kbar13 11y ago
agreed. why optimize for the future when that optimization may directly block/slow your trajectory?
- LoSboccacc 11y agoBecause you have to maintain the app against known vulnerabilities. And in even a single year previous version of out app had multiple gems with vulnerabilities having to do a major version upgrade and I had to scrap the whole thing because older gems with fixes where unavailable or didn't build on modern rail/os The whole ecosystem is frankly a mess, you need to stay bleeding edge all the time to have a chance to long term maintenance and suffer any capricious api update each of your dependency might have because staying on old release and relying on backports is not worth it. I'm not paid to clean other people libraries. If the idea of open source is that, then no thanks. Core business is not maintenance and costs like those do kill startups.
- scott_karana 11y agoIf all your old gems had vulnerabilities, what makes you think bleeding edge ones didn't? Spoiler: the difference is, the new ones' bugs just aren't widely known yet.
- mszyndel 11y ago> you need to stay bleeding edge all the time to have a chance to long term maintenance yeah, github is a perfect example or that, right? </irony>
- deedubaya 11y agoThose aren't rails specific issues. If you want to run on old software that you don't have to upgrade or maintain, you are going to pay for someone else to do it. If you want your cake and to eat it too, you're unrealistic.