5 ms·
> 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
by 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.