3 ms·

> The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge That's completely unrelat

by brabel 6y ago

> The whole software industry moved away from waterfall to agile because it's unreasonable to assume that no requirements will emerge That's completely unrelated to library versioning. The software industry that I work at absolutely relies on library authors to diligently introduce breaking changes only in rare occasions, and preferably using semver to the extent possible. If you can't guarantee your library will be kept up-to-date with bug and security fixes, without me having to re-write my application on minor library updates because you decided to change your API to make it prettier, then I most certainly won't be using your library (indeed, I have removed dependencies from projects I worked on for this reason).

nemothekid 6y ago
>re-write my application on minor library updates This is the tension of semver - a minor library update might include a breaking change, but that doesn't mean you have to rewrite your application. For example, lets say I have a library that returned an int32 in a single function that would silently corrupt your data, but now has to return an int64. The right thing to do would be to issue a major upgrade where the function returns an int64. If you never used this function you wouldn't have to rewrite your application. Major updates in semver only mean backwards compatibility is broken, it doesn't mean it's am whole new api. To me, the Go approach takes your approach to major upgrades - reserve them for when you do something like rewriting the API. That's to me isn't a good assumption to bake in, I'd like to change a single function signature without having to copy my entire library to a new folder.
- Skinney 6y ago
  > To me, the Go approach takes your approach to major upgrades - reserve them for when you do something like rewriting the API. That's to me isn't a good assumption to bake in, I'd like to change a single function signature without having to copy my entire library to a new folder. Then make a new function within the same folder that works in a new way. If necessary, mark the old function as deprecated. An exception can be made if the function never worked to begin with, but that should really have been cought by tests or people using a pre-release version of the library.
barumi 6y ago
> That's completely unrelated to library versioning. It really is not. The initial assertion was that stumbling on breaking changes once per month was somehow a sign that a library isn't ready. Thus assertion flies in the face of the reality of software engineering. If your whole process is designed to allow requirements to emerge then you will have to deal with emergent requirements that you need to accommodate, and in moderately sized projects that always involves changing behavior.
- brabel 6y ago
  > It really is not. You seem to be assuming we use libraries to implement the quickly changing business requirements? If you do that, then sure, you'll have a hard time using versioned libraries at all. But you don't need to do that. Doing that is just a pain. Have a single code base with separate modules by all means, but don't pretend the modules are versioned separately and independent. In other words: don't make them libraries unless you MUST. A library, by definition, is a re-usable software component. Something can only be re-usable when it's stable (if it keeps changing, it's by definition not re-usable as consumers would also be expected to keep changing, and that's not the case for everything as you seem to assume). Things like base64, encryption algorithms, data structures... even spec-backed things like OAuth and HTTP libraries don't just change every month.

by brabel 6y ago

nemothekid 6y ago

>re-write my application on minor library updates This is the tension of semver - a minor library update might include a breaking change, but that doesn't mean you have to rewrite your application. For example, lets say I have a library that returned an int32 in a single function that would silently corrupt your data, but now has to return an int64. The right thing to do would be to issue a major upgrade where the function returns an int64. If you never used this function you wouldn't have to rewrite your application. Major updates in semver only mean backwards compatibility is broken, it doesn't mean it's am whole new api. To me, the Go approach takes your approach to major upgrades - reserve them for when you do something like rewriting the API. That's to me isn't a good assumption to bake in, I'd like to change a single function signature without having to copy my entire library to a new folder.

Skinney 6y ago
> To me, the Go approach takes your approach to major upgrades - reserve them for when you do something like rewriting the API. That's to me isn't a good assumption to bake in, I'd like to change a single function signature without having to copy my entire library to a new folder. Then make a new function within the same folder that works in a new way. If necessary, mark the old function as deprecated. An exception can be made if the function never worked to begin with, but that should really have been cought by tests or people using a pre-release version of the library.

barumi 6y ago

> That's completely unrelated to library versioning. It really is not. The initial assertion was that stumbling on breaking changes once per month was somehow a sign that a library isn't ready. Thus assertion flies in the face of the reality of software engineering. If your whole process is designed to allow requirements to emerge then you will have to deal with emergent requirements that you need to accommodate, and in moderately sized projects that always involves changing behavior.

brabel 6y ago
> It really is not. You seem to be assuming we use libraries to implement the quickly changing business requirements? If you do that, then sure, you'll have a hard time using versioned libraries at all. But you don't need to do that. Doing that is just a pain. Have a single code base with separate modules by all means, but don't pretend the modules are versioned separately and independent. In other words: don't make them libraries unless you MUST. A library, by definition, is a re-usable software component. Something can only be re-usable when it's stable (if it keeps changing, it's by definition not re-usable as consumers would also be expected to keep changing, and that's not the case for everything as you seem to assume). Things like base64, encryption algorithms, data structures... even spec-backed things like OAuth and HTTP libraries don't just change every month.