Spec-ulation – Rich Hickey [video] • Hacker News Board

Re: Spec-ulation – Rich Hickey [video]

#31

Post by sheepmullet » Sat, Dec 03, 2016, 2:28 AM UTC

jjnoakes wrote: post #29

sheepmullet wrote: post #25

Earlier quoted context omitted.

Like Rich mentioned from the point of view of a library consumer it's: PATCH: Don't care MINOR: Don't care MAJOR: You're screwed MAJOR is simply not granular enough and MINOR and PATCH are pointless. Sometimes when I update to a new major version of a dependency it all just works. Other times I've got to spend weeks fixing up all the little problems. Did you break one thing I didn't even use? Update the MAJOR version…

Still don't see the big problem. If the major version is updated and it doesn't affect you, you have a 10 second job to do. If it does, you have a bigger job to do (or don't update). What's the big deal?

How do you know if it's a 10 second job or a bigger job?

Re: Spec-ulation – Rich Hickey [video]

#32

Post by DEADB17 » Sat, Dec 03, 2016, 2:32 AM UTC

taeric wrote: post #27

DEADB17 wrote: post #24

Earlier quoted context omitted.

Wouldn't changing the MAJOR version be equivalent to changing the namespace without altering the human memorable identifier of the package? Understanding that changes in MINOR.PATCH are backwards compatible, is the difference between NAME MAJOR.MINOR.PATCH and NEW_NAME MINOR.PATCH significant? They look to me as just two different conventions.

No. Because I don't have a way to keep the old and the new. That is, the point is that you didn't change my use of the old. You just changed what I actually use. It may work. It may not. This is especially egregious when I had to up versions to get some new functions, and old versions just happen to have changed.

I don't know about maven, but in NPM you can keep both. If you take away the limits of a particular implementation, I think that semantic versioning is a useful convention for the producer of an artifact to convey intent to the consumers.

Re: Spec-ulation – Rich Hickey [video]

#33

Post by jjnoakes » Sat, Dec 03, 2016, 2:45 AM UTC

sheepmullet wrote: post #28

jjnoakes wrote: post #23

Earlier quoted context omitted.

Perhaps, but he repeatedly claimed that the minor and patch numbers conveyed no meaning, while dismissing the semver spec as a manifesto. But if he read and understood it, he'd know those were important numbers. Maybe moreso than the major version. Perhaps he should have argued his actual stance more, instead of the strawman stance. That put me off.

From the point of view of a library consumer why should they care about the patch or minor versions at all? Isn't later = better?

Because if you start relying on something new or fixed in x.2.z of your dependency you want to make sure anyone using your code isn't using x.1.y.

Re: Spec-ulation – Rich Hickey [video]

#34

Post by jjnoakes » Sat, Dec 03, 2016, 2:46 AM UTC

sheepmullet wrote: post #31

jjnoakes wrote: post #29

Earlier quoted context omitted.

Still don't see the big problem. If the major version is updated and it doesn't affect you, you have a 10 second job to do. If it does, you have a bigger job to do (or don't update). What's the big deal?

How do you know if it's a 10 second job or a bigger job?

Read the release notes?

Read the code diff?

Try it?

Re: Spec-ulation – Rich Hickey [video]

#35

Post by sheepmullet » Sat, Dec 03, 2016, 2:49 AM UTC

DEADB17 wrote: post #30

sheepmullet wrote: post #25

Earlier quoted context omitted.

Like Rich mentioned from the point of view of a library consumer it's: PATCH: Don't care MINOR: Don't care MAJOR: You're screwed MAJOR is simply not granular enough and MINOR and PATCH are pointless. Sometimes when I update to a new major version of a dependency it all just works. Other times I've got to spend weeks fixing up all the little problems. Did you break one thing I didn't even use? Update the MAJOR version…

Being screwed would be the case if the consumer of the artifact is forced to upgrade. i.e.: if versions cannot coexist in a code base. Otherwise I think the information that they convey is useful: PATCH: improvement or correction that does not affect the consumers expectation (safe improvement) MINOR: additional features that may be useful directly to the consumer or its transitive dependencies (safe to upgrade) MAJO…

> Being screwed would be the case if the consumer of the artifact is forced to upgrade. i.e.: if versions cannot coexist in a code base.

In theory multiple versions can co-exist in a codebase in js land.

In practice though the vast majority of js libs don't compose well with different versions.

At best I've found it can work as long as you consider them seperate and unrelated libraries (basically the version in js land is part of the namespace).

Edit: I definetly don't think it's as big of an issue in js land as in Java land because of transitive dependency handling.

Re: Spec-ulation – Rich Hickey [video]

#36

Post by sheepmullet » Sat, Dec 03, 2016, 2:50 AM UTC

jjnoakes wrote: post #34

sheepmullet wrote: post #31

Earlier quoted context omitted.

How do you know if it's a 10 second job or a bigger job?

Read the release notes? Read the code diff? Try it?

So lots of manual work. And you still don't see the issue?

Wouldn't it be good if there was some kind of automated way to know?

Re: Spec-ulation – Rich Hickey [video]

#37

Post by sheepmullet » Sat, Dec 03, 2016, 2:53 AM UTC

jjnoakes wrote: post #33

sheepmullet wrote: post #28

Earlier quoted context omitted.

From the point of view of a library consumer why should they care about the patch or minor versions at all? Isn't later = better?

Because if you start relying on something new or fixed in x.2.z of your dependency you want to make sure anyone using your code isn't using x.1.y.

And doesn't automatic dependency resolution make this a non-issue for your consumer?

Edit: I.e. If you declare your own dependencies then tooling should ensure anyone who uses your code uses the same dependencies.

It doesn't work this way in Java world due to technical limitations, but it can in JS world

Re: Spec-ulation – Rich Hickey [video]

#38

Post by jjnoakes » Sat, Dec 03, 2016, 3:04 AM UTC

sheepmullet wrote: post #36

jjnoakes wrote: post #34

Earlier quoted context omitted.

Read the release notes? Read the code diff? Try it?

So lots of manual work. And you still don't see the issue? Wouldn't it be good if there was some kind of automated way to know?

Semver doesn't preclude automating anything, does it?

Re: Spec-ulation – Rich Hickey [video]

#39

Post by prodigal_erik » Sat, Dec 03, 2016, 3:09 AM UTC

sheepmullet wrote: post #37

jjnoakes wrote: post #33

Earlier quoted context omitted.

Because if you start relying on something new or fixed in x.2.z of your dependency you want to make sure anyone using your code isn't using x.1.y.

And doesn't automatic dependency resolution make this a non-issue for your consumer? Edit: I.e. If you declare your own dependencies then tooling should ensure anyone who uses your code uses the same dependencies. It doesn't work this way in Java world due to technical limitations, but it can in JS world

That limitation is healthy. If versions 1.1 and 1.2 of a class exist and I'm foolish and determined enough to use both in the same process (via multiple classloaders), Java will still ensure that I can't accidentally give a 1.1 instance to a callee expecting a 1.2 instance, or vice versa. Version mismatches at call sites fail quickly and loudly with classloading exceptions.

I think a hell of a lot of NPM packages only appear to work by accident, and over time they'll fail because of sloppiness about this.

Re: Spec-ulation – Rich Hickey [video]

#40

Post by taeric » Sat, Dec 03, 2016, 3:11 AM UTC

DEADB17 wrote: post #32

taeric wrote: post #27

Earlier quoted context omitted.

No. Because I don't have a way to keep the old and the new. That is, the point is that you didn't change my use of the old. You just changed what I actually use. It may work. It may not. This is especially egregious when I had to up versions to get some new functions, and old versions just happen to have changed.

I don't know about maven, but in NPM you can keep both. If you take away the limits of a particular implementation, I think that semantic versioning is a useful convention for the producer of an artifact to convey intent to the consumers.

That is the point. It doesn't convey intent. Outside of the "major versions could break." Which is somewhat worthless.

Consider, you are using a library that expose ten objects and functions. It is on version 1.2.8. it upgrades to 1.2.9. What do you do? You take the upgrade. Usually no questions asked.

It upgrades to 1.3.0, but only to add an eleventh function. What do you do? Probably take it, because you don't want to be behind.

It upgrades to 2.0. reason is "things have changed.". However, they kept the same function names. You think you can make the upgrade fine. Because, well they have the same names. However, you can't know, because some body thought it wise to reverse arguments of some functions. Which thankfully, is a compile time fail. What else changed, though?