core: release 1.1.0 about libuv HOT 12 CLOSED

No objections from me.

To prevent this from happening again, we might want to bump the minor and reset the is_release thing if a new API is added, thus indicating which version needs to be the next one.

The downside I see with that is that if two people add new APIs and neither is paying attention, then the minor gets bumped twice. Someone still needs to do a manual check, might as well be the person doing the release.

On the other hand, releases happen more frequently than new APIs so it might an acceptable trade-off. I'll go along with whatever you and @piscisaureus agree on.

from libuv.

Related to this, we should add the "versionadded" sphinx thingy for new APIs: #60

from libuv.

@saghul Is the 1.0.2 release going to be re-released so that it doesn't contain this new API?

from libuv.

@misterdjules I'd say no, "damage" is done. It's a new API, we didn't break an existing one, so I can live with it. It's also documented: http://docs.libuv.org/en/v1.x/loop.html#c.uv_loop_configure

So, if the SemVer police comes by, I'll talk to them :-)

from libuv.

I agree. You can't re-release a release; once people have downloaded it, it's out there. Changing it after the fact only leads to confusion ("hey, why does the checksum no longer match?").

from libuv.

Ok, #58 landed, which I wanted to include for this release. Any objections to making a 1.1.0 release tonight? Since I'm there I might as well release a 0.10.x.

from libuv.

@saghul Go for it.

from libuv.

if the SemVer police comes by, I'll talk to them :-)

Here we are! 🚓

You can't re-release a release; once people have downloaded it, it's out there. Changing it after the fact only leads to confusion ("hey, why does the checksum no longer match?").

Seconded. This is a big part of the reason why npm moved to not allowing force-republishing.

Also, minor version bumps should be a little more forgiving than major version bumps: you're only adding new APIs, not making changes that will affect downstream consumers unless they choose to opt into them (knowingly or otherwise).

🚔

from libuv.

Maybe the 1.0.2 release should be deleted, though, since it isn't 1.0.2, by semver?

Deleted from here: https://github.com/libuv/libuv/releases and perhaps even the tag, though that might live on in forks.

Are there tarballs? I can't find them, but if they are somewhere, the broken 1.0.2 should be deleted from there, too, IMO.

from libuv.

I disagree. It would be a different story if the 1.0.2 release contained a serious vulnerability that puts people at risk, but we're just talking about new functionality that was accidentally introduced in a patch release. Unfortunate, perhaps, but ultimately no big deal.

from libuv.

I'm with Ben. 1.0.2 just contains a new API, which can be version checked
just fine. Semantically it should have been 1.1.0, but the change is simple
enough not to overcomplicate things.
On Dec 23, 2014 11:12 PM, "Ben Noordhuis" [email protected] wrote:

I disagree. It would be a different story if the 1.0.2 release contained a
serious vulnerability that puts people at risk, but we're just talking
about new functionality that was accidentally introduced in a patch
release. Unfortunate, perhaps, but ultimately no big deal.

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

from libuv.

I just released 1.1.0 (and 0.10.31) so, I'll close this and try not to forget next time!

@othiym23 sorry sir, it won't happen again, I promise! 😄

from libuv.