Earlier quoted context omitted.
Who says you have to maintain old code? We're talking about simply not deleting it and establishing a discrete semantic for the new version as truthfully, a new version is new content which demands a new name to accurately and precisely describe it. If it didn't it would be like saying different content doesn't produce a different hash.
Except that naming things is one of the hard problems. I don't see why a major version bump can't be considered a different library. I guess you can use version numbers in the name instead, since this talk is specifically targeting maven artifacts.
Spec-ulation – Rich Hickey [video]
71–74 of 74 posts
Re: Spec-ulation – Rich Hickey [video]
#72Earlier quoted context omitted.
Who says you have to maintain old code? We're talking about simply not deleting it and establishing a discrete semantic for the new version as truthfully, a new version is new content which demands a new name to accurately and precisely describe it. If it didn't it would be like saying different content doesn't produce a different hash.
You're right, there is no obligation to maintain it. I think that misses the point though. The value in keeping the code is to allow the end user to continue to enjoy improvements in parts of the library that don't have breaking changes without upgrading those that do. You could continue to have security patches installed, for example. That value is much less when you don't do basic maintenance implement bug fixes an…
Re: Spec-ulation – Rich Hickey [video]
#73Re: Spec-ulation – Rich Hickey [video]
#74This is a very thick talk, one Rich's best ever IMHO. The first point is how we talk about 'change' in software, to center around what things 'provide' and 'require'. Breaking changes are changes that cause code to require more or provide less. Never do that, never need to do that. Good changes are in the realm of providing more or requiring less. There is a detailed discussion about the different 'levels' - from fun…
I found value in dissecting the different levels of change. For the sake of sanity though, we should do breaking changes. Breaking changes exist because we have limited capacity as individuals and an industry to maintain software. This is especially true for infrastructure that is supported by (limited) corporate sponsorship and volunteers. Breaking changes limit our window of focus to two or three snapshots of code,…