Hacker News new | ask | show | jobs
by fbuilesv 4731 days ago
If you "have no problem with keeping software up-to-date" then don't complain about these type of changes. As developers we either are responsible about version policies or we're not. Let's take Ruby 1.8.7 as an example:

If you were responsible you went through several patchlevels of Ruby 1.8.7, you're using the latest release (to fix security issues if nothing else) and you had five years to migrate to 1.9 (which most likely meant changing nothing in your code, just testing it).

If you were not responsible and you're running on something different to the latest patchlevel version then you're already running on faulty/unsecure software. Killing support upstream (again, after five years!) is not likely to change whatever you were [not] doing.

PS: Please don't refer to people like the ruby-core team as "cool kids who easily get bored". We all have our biases but name-calling doesn't add anything useful to discussions.

1 comments

> and you had five years to migrate to 1.9

Given that you were at the project right from the start and allowed to spend time necessary. It's funny to hear people moan on the one hand about corporate that use Java EE or even Cobol but on the other hand refuse to accept that in order for their software to be usable, it needs to be stable in some senses.

When you joined a project is irrelevant. If you were hired two days ago and only found out about this now: tough luck, you have some work to do [0]. Even "stable", older platforms like Cobol have to deal with this (Micro Focus makes money off it with products like their Cobol set of tools (http://www.microfocus.com/mcro/cobol/index.aspx) [1]).

[0] Or maybe not. Your non-core [2] apps that run on 1.8.7 will still work tomorrow. Most of these applications are internal too so the risk is even less.

[1] There's almost always a 3rd party vendor who'll take advantage of a situations like this. They will make it your life easier and they'll charge you accordingly. See http://railslts.com/ for another example.

[2] If the applications that are putting the food on your table are running in an environment where no one thinks about this kind of stuff, then maybe it's time to take the wheel and start educating your team on why this is important.

[0] Precisely.

[1], [2] After all management does such decisions. I have warned people face-to-face, via E-Mail, through all possible channels. So if things go wild, it's their problem, not mine.