stop using semver

[jonathanong]

what do you guys think about switching to this crazy idea i had today: https://github.com/jonathanong/ferver

main goal is to stop pinning deps that use ferver and instead use ~ so @dougwilson doesn't spam the commit log with dep updates =P

for express, we can release 5.y.z immediately without any changes (or maybe a few) except a note that we'll use ferver, to never depend on express with ^, and to not expect a 6.0.0. this way, we could get rid of half of the current issues immediately as well as iterate on the router and such.

[dougwilson]

@jonathanong I am reading and digesting it. I can say, at least, that I think I am O.K. with referencing between our own things with ~, but not sure I completely trust upstreams, because I still get people breaking things a lot with the path bump :(

for express, we can release 5.y.z immediately without any changes

at least for now, we should probably try the scheme on something not quite as visible as express, especially if we end up tweaking it or something.

[Fishrock123]

I don't think I like the 0.x.x dev channel thing very much.

It is far better more sane to use odd and even version numbers, imo.

[dougwilson]

I don't think I like the 0.x.x dev channel thing very much.

Yea, I also think that is weird. node.js uses the odd/even just like perl 5 does.

[Fishrock123]

For example: 0.3.0 -- which is this a dev version for? 2.3.0? 17.3.0? What if you need both?!

Maybe I'm not understanding it, but I still don't like it.

[jonathanong]

the problem with odd and even versioning is that it's not compatible with semver.

why would there be 2.3.0 and 17.3.0? there should be no way the major is higher than the minor since each major bump requires at least 1 minor bump and the minor never resets. and if you're bumping the major 17 times somethings wrong.

for small stuff i'd rather just bump the major more to confuse people less. this matters for express because you don't want to be bumping the major every few months but you still want fixes with breaking changes in within a reasonable time

[jonathanong]

main point is to use <major-breaking>.<minor-breaking>.<non-breaking> versioning instead of <breaking>.<feature>.<patch> so that we can safely use ~ with our own stuff. dev stuff doesn't really matter except for shit that needs a lot of testing before any release (can't think of any of our libs that need that)

[dougwilson]

main point is to use .. versioning instead of .. so that we can safely use ~ with our own stuff

yes, this. that i am not iffy about :)

[Fishrock123]

I thought that <patch> ~= <non-breaking> but.. eehhh

How do we objectively differentiate between major and minor breaks?

[dougwilson]

How do we objectively differentiate between major and minor breaks?

According to the docs, if you are not sure, it is minor-breaking.

[Fishrock123]

Wait with ferver you don't reset the minor?

This will only cause lots of confusion >.<

[dougwilson]

Wait with ferver you don't reset the minor?

I feel the same way. Right now I think the only consensus is that if you're in doubt on if the change is not breaking or slightly breaking, bump the minor, not the patch.

[jonathanong]

For tiny libraries like those in this org, it would be easier to skip minor versions all together.

Not resetting the minor will cause confusion if you just look at the release history, but I don't think anyone will do that (because I don't know how you would). All the changes in the commit log will have incrementing numbers except the major switches when it's a release.

[jonathanong]

okay i updated the docs and removed the dev channel (since i can't think of a project it would even be useful). if you all agree, i'd like to make it official in the org.

[dougwilson]

OK, generally seems fine. Even the few repos I have that is still at 0 is because they are still experimental. I should probably promote a couple after re-evaluating.

[Fishrock123]

I still think minors should reset with majors, but the rest seems ok, though I haven't re-read it thoroughly.

[jonathanong]

The resetting stuff was part of the dev channel stuff that is removed, so don't worry, it's still being reset :P

[dougwilson]

@jonathanong I just finished reading your blog post on this and it's awesome :)

[defunctzombie]

I am against switching away from pinned dependencies. Code should be fixed for a release because that is what we have tested. Developers break random crap and release patch versions.

I am OK with minor versions introducing some breaking changes simply because too many people look at major versions as some sort of media event. With an up to date changelog I thing we will be fine.

[defunctzombie]

I should add that all the dep update commits are great because if a dep breaks then we can track it down to an update commit. It follows nicely.

[jonathanong]

@dougwilson has been doing all the updates, so it's really up to him if he wants to continuously do that. My only goal is to be able to ~ our own shit without breaking stuff whenever we get lazy

[dougwilson]

I am against switching away from pinned dependencies. Code should be fixed for a release because that is what we have tested. Developers break random crap and release patch versions.

I know, and I'm still against not pinning against the libraries we do not control (i.e. I still think we should pin against "foreign" libs). So far I'm only thinking of maybe ~ against our own inter-dependencies. Really, this whole headache goes away for the most part with express@4/connect@3 since they do not have a bazillion dependencies.

[rlidwka]

As @balupton said earlier in npm/npm#4587 (comment), npm version system should be redefined this way:

revisions = no b/c breaks
minors = b/c breaks for some
majors = b/c breaks for everyone

I think we could just borrow that definition.

[dougwilson]

Down with the ^

[defunctzombie]

semver... rofl

[jonathanong]

that's what my ferver is basically, but i think "breaks for some" should really be "breaks or might break for some"

[Fishrock123]

Hardcore semver is dumb, but I'm also not sure we should totally follow this ferver thing.

Can we just close this and say we go with a sorta soft-semver?

[dougwilson]

If it helps, I do try to follow semver as much as possible (since, of course, npm forces node library to), but sometimes I can introduce slightly breaking changes on a minor version bump on purpose. Sadly it's harder to do this today than ever before because so many people use npm install --save <blah> which adds the version with a leading ^.

[defunctzombie]

They deserve what they get for introducing stupid defaults.
On Sep 14, 2014 10:05 PM, "Douglas Christopher Wilson" <
notifications@github.com> wrote:

If it helps, I do try to follow semver as much as possible (since, of
course, npm forces node library to), but sometimes I can introduce slightly
breaking changes on a minor version bump on purpose. Sadly it's harder to
do this today than ever before because so many people use npm install
--save which adds the version with a leading ^.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[rlidwka]

Can we just close this and say we go with a sorta soft-semver?

This way you'll get a bunch of angry users after each minor breaking change.

I think we should say a few words in readme's about versioning system, and ask people to use ~. You still can follow semver this way and avoid breaking stuff, but in case you do break it, at least it will go more smoothly.

[Fishrock123]

I still don't understand the difference between ~ and ^ lol

[rlidwka]

Hardcore semver is dumb, but I'm also not sure we should totally follow this ferver thing.

The thing is that ferver does have a recognizable name, and "we follow semver but not really"-style versioning does not.

Maybe add a table at the footer of the README that lists all information that is rarely changed (as opposed to badges that change frequently). Something like this:

Code Style	Versioning	License
jshttp	ferver	MIT

[dougwilson]

Unfortunately as long as we are published on npm, we can't not use semver unless we want lots of angry users all the time and people just not using the modules. npm forces semver on all the modules.

[defunctzombie]

Npm doesn't force anything.
On Sep 15, 2014 8:25 AM, "Douglas Christopher Wilson" <
notifications@github.com> wrote:

Unfortunately as long as we are published on npm, we can't not use semver
unless we want lots of angry users all the time and people just not using
the modules. npm forces semver on all the modules.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[dougwilson]

It does with npm install --save, which is advertised all over the place as how to add your dependencies. A lot of people don't even know what ^ or ~ means in the version listed (even @Fishrock123 apparently), let alone that the dependencies are listed in the package.json fiile.

[defunctzombie]

This is a problem with developer education. You cannot simply use a
dependency system and not understand even the slightest thing about it. We
should just say something in the docs or readme about our versioning style
and suggest users learn their tools. NPM is 100% at fault for introducing
^ as a default thinking they somehow rule the universe with how people
release software. They do not understand anything about the reality of
software releases over time. /rant

On Mon, Sep 15, 2014 at 8:38 AM, Douglas Christopher Wilson <
notifications@github.com> wrote:

It does with npm install --save, which is advertised all over the place
as how to add your dependencies. A lot of people don't even know what ^
or ~ means in the version listed (even @Fishrock123
https://github.com/Fishrock123 apparently), let alone that the
dependencies are listed in the package.json fiile.

—
Reply to this email directly or view it on GitHub
#4 (comment).

[rlidwka]

Unfortunately as long as we are published on npm, we can't not use semver

Yes, we can. I'm now looking at the most popular modules, coffee-script doesn't use semver (they routinely break minors), jquery doesn't use semver (they use majors for a completely different thing). You know, even npm itself didn't use semver until now.

It does with npm install --save, which is advertised all over the place as how to add your dependencies.

That's exactly why I suggested to mention this in README. People need to learn this, not blindly follow npm defaults.

[dougwilson]

Like I said, I don't publish strict semver modules, either, but I try to make them really close to semver. I basically use a less extreme compromise between semver and ferver, where minor doe snot solely mean "Minor breaking changes", but may contain minor breaking changes if I really feel that I must.

[Fishrock123]

http://fredkschott.com/post/2014/02/npm-no-longer-defaults-to-tildes/

oh for pete sake npm

We should just advocate major bumping.

[jonathanong]

for these modules, we should be using semver but bumping minor more liberally. the ferver crap is more for bigger projects like express that cant semver as easily. it's up to @dougwilson for express, but i think with v5+ he should deprecate, wait 3-6 months, remove/change vs. waiting until the next major version.

[rlidwka]

About express: yeah, full-blown ferver with constantly breaking minors fits better here, but it's up to you really.

About small jshttp packages:

Current versioning system is fine, but it's not semver. It's very close to it, but it is not. So even if breaking changes are rare, sometimes you have to do them, and if you claim you use semver, you'll get a bunch of angry users complaining.

I don't suggest to change it, but it's worth to discuss about how we tell users about breaking changes. Maybe put big bold "breaking" heading in "history.md" every time it happens.

[rlidwka]

Also, semver does allow breaking bugfixes in patches. But for this org it'll be useful to forbid them as well, thus "ferver in semver-like mode" would work a bit better.

[dougwilson]

Eh. Perhaps we just add a Versioning section to the bottom of the readme above the License section with something like:

When depending on this module using npm, it is recommended to depend on a specific version, or just the major + minor (i.e. ~1.1.0, 1.1.x, etc.). When the minor version is changed, there can potentially be minor breaking changes, depending on how the module is being used (though no API changes).

[rlidwka]

I agree. If only we could find a way to avoid having that boilerplate in every readme, that'd be awesome.

[rlidwka]

Add versioning.md in this repo, and duplicate it everywhere? Same for code style.

[Fishrock123]

duplicate it everywhere? Same for code style.

In every repo? please no.

[Fishrock123]

If we must, put a table somewhere with links to this stuff

[dougwilson]

How about we add a document about this somewhere in jshttp (like either on the github pages or just in the repo) and write:

When depending on this module using npm, it is recommended to depend on a specific version, or just the major + minor (i.e. ~1.1.0, 1.1.x, etc.). For more information, please see the jshttp versioning policy.

That'll give the most important information up-front and a link to the full policy.

[Fishrock123]

eh, gona close this, seems like the consensus is "semver: the sensible parts"