3 ms·

It’s relatively actionable as well. When someone says they want to migrate from Rails 4 to 5, the default response is “we should really consider doing that at s

It’s relatively actionable as well. When someone says they want to migrate from Rails 4 to 5, the default response is “we should really consider doing that at some point and evaluate how much work it will take.” When they say we want to migrate from Rails 4 to Django X, the default response is “you’re going to have to justify a total rewrite”. That’s even true for some brutal version changes: going from Python 2 to Python 3 is still typically less work than going to Go or Java or some other language. Angular might be the one exception I know of to this pattern.

grzm 9y ago
I agree that there are degrees of difference that can be conveyed. I think there's a bit of a misconception of what it can mean to rename a library, however, that's often (and understandably easily) missed in this particular discussion. There are at least three levels where the names matter: the project (e.g., Rails), the artifact (e.g., a particular gem), and the module(s) (e.g., what gets referenced by require). They're each important in their own way. I think renaming the Rails project instead of a major version bump is not what is typically the intent when talking about renaming. Artifacts are a way of referencing a collection of files, and often there's some way of embedding metadata about the artifact in the name of it, though that's accidental, and naming these artifacts is independent (or at least not necessarily dependent) of the collection it represents: the same file can be found in any number of artifact builds. I think the practical implication is that you're renaming what is being required and referenced in the code itself. So, you'd still have the same understanding that a migration from Rails2 to Rails5 would be bigger than one from Rails4 to Rails5, and that would be a whole different kettle of fish than moving to Django (or even Sinatra). I think we may be talking past each other as to the level where renaming (or really, new, additional naming) would take place.

grzm 9y ago

I agree that there are degrees of difference that can be conveyed. I think there's a bit of a misconception of what it can mean to rename a library, however, that's often (and understandably easily) missed in this particular discussion. There are at least three levels where the names matter: the project (e.g., Rails), the artifact (e.g., a particular gem), and the module(s) (e.g., what gets referenced by require). They're each important in their own way. I think renaming the Rails project instead of a major version bump is not what is typically the intent when talking about renaming. Artifacts are a way of referencing a collection of files, and often there's some way of embedding metadata about the artifact in the name of it, though that's accidental, and naming these artifacts is independent (or at least not necessarily dependent) of the collection it represents: the same file can be found in any number of artifact builds. I think the practical implication is that you're renaming what is being required and referenced in the code itself. So, you'd still have the same understanding that a migration from Rails2 to Rails5 would be bigger than one from Rails4 to Rails5, and that would be a whole different kettle of fish than moving to Django (or even Sinatra). I think we may be talking past each other as to the level where renaming (or really, new, additional naming) would take place.