4 ms·

The larger discussion about whether or not package maintainers have a responsibility to minimize user frustration at the cost of their own opinions and practice

by akerl_ 12y ago

The larger discussion about whether or not package maintainers have a responsibility to minimize user frustration at the cost of their own opinions and practices is worthwhile. If I'm the author of an unpopular module, where I am the sole user, and I don't like semantic versioning or some other facet of package management, I don't follow it. Should I be expected to change my stance just because other people begin using my project? At what point is my project's community large enough that maintaining a healthy ecosystem involves sharing some control over the practices with that community? It also doesn't help here that rather than having a rational discussion, the author released what can only be described as a troll package, where every version change becomes a major version. Using that would be the height of insanity, as noted in the issue thread, because all libraries would need to update their dependencies and re-release with every Underscore-semver release, due to dependency version conflicts.

rubiquity 12y ago
> It also doesn't help here that rather than having a rational discussion, the author released what can only be described as a troll package, where every version change becomes a major version. What exactly about Jeremy Ashkenas makes you think this was done as a way to troll people? He still took a lot of time to make release notes and note all of the changes.
- abritishguy 12y ago
  A maintainer did that.
  - krebby 12y ago
    Yup. I'm the contributor who wrote that pull for the release. You can see the original here https://github.com/jashkenas/underscore/pull/1799 https://github.com/jashkenas/underscore/pull/1799
- akerl_ 12y ago
  I was referring specifically to the underscore-semver package, not the Underscore project as a whole. Using it in actual projects isn't feasible in any way, because it would require that your project and any project you depend on that also depends on underscore-semver specify the exact same version, or else we're back with the same problem as before. And since you won't be a package maintainer for everything your depend on in most cases, that isn't feasible. He's not released a version that obeys semver, he's released a version that treats any update as a breaking change.
  - rubiquity 12y ago
    Ah, I didn't realize you were talking about underscore-semver. I'm sure that was done tongue in cheek. > He's not released a version that obeys semver, he's released a version that treats any update as a breaking change. SemVer isn't a law. It's a set of guidelines for versioning software in a slightly less arbitrary way. Maybe extra precaution could be taken for something as common as underscore, and to me that is the only argument worth having here.
    - akerl_ 12y ago
      Maybe I'm biased by not having a widely used open source project, and my judgement is thus clouded by wanting to one day have a community of users for something that I've written. That said, I do write code and have tools that are used by other groups of people, and have experienced feature requests and suggestions and patches that I don't necessarily agree with, and I've always tried to step back and consider the overall impact on the project rather than my personal preconception of what the project "should" be. I've merged features that I'd never use and adjusted things to make my project more friendly for users who aren't me. I think that one of the greater things about open source projects is that over time the original author can focus more on the fun parts or on guiding the overall direction of the project, because the community can provide assistance with identifying issues and maintaining existing systems. Whether the version number is 2.0.0 or 1.7.0 or 50.0.0 is such a trivial thing, and as a developer I'd imagine I'd make my choice based on what made my project more usable for the community.
    - 12y ago
- jashkenas 12y ago
  The Underscore-semver package is a bit of a troll package — it's the literal-minded SemVer way of versioning Underscore. Historically, nearly every single release has had at least one thing that mildly changed the behavior of some minor edge case or other. So by strict SemVer, if we wouldn't be at version "170.0.0" by now, we'd be damn close to it.
  - markdodwell 12y ago
    Why does that matter? Are big numbers inherently bad?

by akerl_ 12y ago

rubiquity 12y ago

> It also doesn't help here that rather than having a rational discussion, the author released what can only be described as a troll package, where every version change becomes a major version. What exactly about Jeremy Ashkenas makes you think this was done as a way to troll people? He still took a lot of time to make release notes and note all of the changes.

abritishguy 12y ago
A maintainer did that.
- krebby 12y ago
  Yup. I'm the contributor who wrote that pull for the release. You can see the original here https://github.com/jashkenas/underscore/pull/1799 https://github.com/jashkenas/underscore/pull/1799
akerl_ 12y ago
I was referring specifically to the underscore-semver package, not the Underscore project as a whole. Using it in actual projects isn't feasible in any way, because it would require that your project and any project you depend on that also depends on underscore-semver specify the exact same version, or else we're back with the same problem as before. And since you won't be a package maintainer for everything your depend on in most cases, that isn't feasible. He's not released a version that obeys semver, he's released a version that treats any update as a breaking change.
- rubiquity 12y ago
  Ah, I didn't realize you were talking about underscore-semver. I'm sure that was done tongue in cheek. > He's not released a version that obeys semver, he's released a version that treats any update as a breaking change. SemVer isn't a law. It's a set of guidelines for versioning software in a slightly less arbitrary way. Maybe extra precaution could be taken for something as common as underscore, and to me that is the only argument worth having here.
  - akerl_ 12y ago
    Maybe I'm biased by not having a widely used open source project, and my judgement is thus clouded by wanting to one day have a community of users for something that I've written. That said, I do write code and have tools that are used by other groups of people, and have experienced feature requests and suggestions and patches that I don't necessarily agree with, and I've always tried to step back and consider the overall impact on the project rather than my personal preconception of what the project "should" be. I've merged features that I'd never use and adjusted things to make my project more friendly for users who aren't me. I think that one of the greater things about open source projects is that over time the original author can focus more on the fun parts or on guiding the overall direction of the project, because the community can provide assistance with identifying issues and maintaining existing systems. Whether the version number is 2.0.0 or 1.7.0 or 50.0.0 is such a trivial thing, and as a developer I'd imagine I'd make my choice based on what made my project more usable for the community.
  - 12y ago
jashkenas 12y ago
The Underscore-semver package is a bit of a troll package — it's the literal-minded SemVer way of versioning Underscore. Historically, nearly every single release has had at least one thing that mildly changed the behavior of some minor edge case or other. So by strict SemVer, if we wouldn't be at version "170.0.0" by now, we'd be damn close to it.
- markdodwell 12y ago
  Why does that matter? Are big numbers inherently bad?