Why no curl 8

http://daniel.haxx.se/blog/2013/03/23/why-no-curl-8/

141 45 13 years ago

daniel.haxx.se

rubyrescue4• 13 years ago

this reminds me of the time at Microsoft with Visual Studio 6 where the version comparison was a string compare, but build numbers were julian dates, with 4 digits - 9365 was december 31st, 1999.

so we couldn't go from 9365 to 0001. So we just went to 9366 and so we had 999-366 days to sort out a better version numbering system.

itafroma• 13 years ago

Why Julian?

rubyrescue4• 13 years ago

it was an artifact of the build system at the time that i think was inherited from VC++

yuhong• 13 years ago

MS eventually promised to support VB6 runtime and ActiveX controls for the lifecycle of the OS, which is basically forever. Fortunately, there hasn't been that many security updates and hotfixes later on (the latest mscomctl.ocx is 6.1.9834).

klodolph• 13 years ago

Those aren't Julian dates. Julian dates are just a count of days since some epoch, so the day after 9365 would be 9366, then 9367, etc.

mikeash• 13 years ago

Took me a lot of head scratching before I realized that the system was just YDDD, where Y is the last digit of the year (in this case, 9) and DDD is the number of days into the year (so 365 is December 31st in normal years).

This is definitely the weirdest example of the Y2K problem I've seen.

haberman• 13 years ago

Which, it should be noted, is unrelated to the Julian Calendar. That one confused me for a while.

rubyrescue4• 13 years ago

yeah i was going to say that i know they aren't truly julian dates but... i figured someone else would point it out. i guess you could think of it as the last 3 digits are julian dates but they just reset every year?

chubot• 13 years ago

Makes sense, thanks for providing meaningful version numbers. I'm looking at you Chrome, and now Firefox :)

ditoa• 13 years ago

Honestly I don't have an issue with Firefox/Chrome for the rapid version number increases. A browser is the most updated (or should be) bit of software on your computer. Honestly I don't even think of the version of Firefox or Chrome these days. They are just "Firefox" and "Chrome". This is much better for general users IMHO as it just means they use "Firefox" and not "Firefox 4.1.2" or whatever. A consistent update schedule makes a public version number pointless and it has, at least in my experience, made extension developers better at building extensions that don't break because I have upgraded from version 15 to 16 like we had back in the Firefox v2/3/4 years.

At the end of the day when the version number isn't really known to the end user it makes little difference if you bump up the major version number or the minor.

Also I love how quickly we get new features now. Firefox has improved more in the past year than it did in the past several years before the shift to a 6 week release cycle. It isn't suited to all software I admit but for a browser it is perfect. None of this "This site only works with Firefox XX or Chrome XX". Thank god!

LeonidasXIV• 13 years ago

> at least in my experience, made extension developers better at building extensions that don't break because I have upgraded from version 15 to 16 like we had back in the Firefox v2/3/4 years.

This is more caused by Firefox stopping to break the compatibility all the time. The plugin API in Firefox used to be just the internals, exposed to JS, so everytime something changed, it broke extensions. These days, they stopped doing that quite as often plus they published the Jetpack SDK which promises a stable API at the cost of less possibilities to change the browsers behaviour.

kelnos• 13 years ago

Meaningful versioning (aka "semantic versioning", http://semver.org/) isn't super important for an application. It's super important when dealing with libraries, of which libcurl is.

dkarl• 13 years ago

It's important when an application has a plugin or extension API.

tomku• 13 years ago

SemVer is great for versioning APIs and the libraries that expose them, but very poor for versioning complex user-facing apps that are composed of many parts. Do you increment the major version when you have a backwards-incompatible change in the Javascript engine? In the layout engine? In the DOM API? In the preferences storage format? In the plugin API? How about if you completely remade the UI (which could be argued is the "average user's API"), but kept all the programming APIs the same? Each release of Firefox is a composite of many parts, each of which may or may not have breaking changes.

I think that what Chrome (and later Firefox) ended up doing is a pretty good compromise. The major version of Chrome is basically "Chrome" - if they ever break compatibility in any kind of major way, it probably will be as a different project. Firefox is the same way.

I know that it'd be great if you could derive deep secrets about the changes in each release from just the version number, but that just doesn't scale to complex projects. Use SemVer and similar schemes where they're appropriate, but don't treat them like they're the only right choice.

fafner• 13 years ago

In what way is their version number scheme meaningful? They broke abi compatibility in the past without changing major version numbers and now they say they won't break the abi and compatibility and that's why they aren't changing major version numbers...

Where is the meaning? At least for Chrome/Firefox you know x+1 means another six weeks are over...

mbrubeck• 13 years ago

Firefox actually does break ABI compatibility with every release (for the minority of extensions that use binary code that links to Firefox libraries). So according to traditional version numbering dogma, Firefox is doing exactly the right thing by incrementing the major version number with every release.

benatkin2• 13 years ago

This is good. It's very good to have things that just won't break. The successor to curl 7 should probably not be called "curl", just like the successor to JSON, if there is one, should not be called "json".

rajanikanthr• 13 years ago

Curl is good..but as a .NET programmer httpie(https://github.com/jkbr/httpie) and Fiddler are suffice to me

manojlds• 13 years ago

Httpie should suffice for any, well like they say, human.

benatkin2• 13 years ago

The post is mainly about the library, not the command-line interface.

justin66• 13 years ago

> These distributions only want one version of the lib, so when an ABI bump is made all the applications that use the lib will be rebuilt and have to be updated.

That's... a big deal?

Relative to everything else that goes on in making a distribution, it seems pretty trivial.

zdw• 13 years ago

The problem is that putting together the distribution is "someone else's work", not the work of application software developers. The division of labor has always put everything on the distro maker, and almost none on the developer.

There's no automated pipeline of code -> build -> distro package -> testing happening, because almost everyone is still stuck in the bad old days of "download the tarball and compile it" and if you're really lucky you get a checksum on the tarball.

Ideally, we'd move to some automated means of putting together software. Imagine if there was GitHub/TravisCI style automatic process that spit out packages for Linux/BSD/Solaris/OS X/etc. on every checkin. That's where we need to go.

icebraining• 13 years ago

Well, Debian has git-buildpackage, which creates .deb packages from git repositories, and can use the commit log for the package changelog.

The problem is, unless the upstream dev uses Debian, why should he care?

shurcooL2• 13 years ago

What are the reasons not to follow semver today?

kscaldef• 13 years ago

I'm not sure, but you may be misunderstanding the article. As far as I can tell, they _are_ following semver, and the discussion is about why they would go to extreme measures to maintain the same major version for 13 years an avoid a binary incompatibility. In other words, it's not that they don't recognize the value of semver, but that they are also considering the cost to users of the varying types of version bumps.

shurcooL2• 13 years ago

I think my question is misunderstood also.

I realize they follow semver (at least unofficially), which I think is great. What I want to know is if there any good reasons why others don't do it?

rwmj• 13 years ago

The best thing libvirt[1] does is to have a stable API from day 1. Over 7 years and counting. In practice this means a couple of things: We have to be careful and considerate when introducing any new API, since we're going to be maintaining it for a very long time. And although we do deprecate APIs occasionally, we keep them around forever so programs don't need to be "fixed" all at once (or maybe never).

[1] http://libvirt.org

brokentone• 13 years ago

Finally someone who:

1. Thought through the application/library from the beginning so that new features and changes are binary compatible.

2. Is considerate of the distribution/repository world we live in, doesn't just say "ain't my problem"

3. Doesn't just add numbers to do it.

Good work sir, stay strong curl 7

endgame• 13 years ago

Not only that, but libcurl's documentation has some of the best structure I've ever seen.

skrebbel2• 13 years ago

that's just to make up for a ridiculously insane API.

Kiro• 13 years ago

I never understood the strictness surrounding version numbering. We've had long discussions at work whether a release should be called 4.2 or 4.1.4. Who cares and why does it matter?

agwa• 13 years ago

It matters because a good versioning system indicates to users what to expect from the release. If version numbers are major.minor.patch, then incrementing the patch number should indicate that you've only fixed bugs and it should be safe to install without risking new bugs. Incrementing the minor number should mean you've made feature changes but everything is backwards compatible. Incrementing the major number should mean you've made major changes that break compatibility.

See http://semver.org/ for more details.

Edit: others have pointed out that this is more important for libraries and less so for user-facing applications. For user-facing applications I'd recommend two version numbers so you can distinguish between feature releases and bugfix-only releases, which can be a useful indicator to the end user.

qntmfred• 13 years ago

I'm glad they've decided to address this 13 years into v7?

anonymous• 13 years ago

A minor nitpick:

> These distributions only want one version of the lib, so when an ABI bump is made all the applications that use the lib will be rebuilt and have to be updated.

This is not true, at least on Archlinux. Currently I have 5 different versions of libpng installed:

local/lib32-libpng 1.5.14-1

local/lib32-libpng12 1.2.50-2

local/lib32-libpng14 1.4.11-2

local/libpng 1.5.14-1

local/libpng12 1.2.50-2

Spidler• 13 years ago

As someone who's been in the distribution business a couple of years ago, I can tell that it isn't as well supported in practice.

Imagine for example, a rather classical stack. Let's take KDE cause they are on the top of the news.

we have libpng 1.2.x With headers in include/libpng/. ( This is wrong, very acute of you to notice. ) We link kdelibs to libpng-1.2 ( independent use, inherited link ) We link kicker to libpng-1.2 ( kicker uses some things from libpng as well. Yey )

New version of libpng is installed, 1.4. Breaking ABI but not API in the process! If this version is installed in "include/libpng/" You'll link future versions of kicker against this. This gives the chain:

kdelibs : libpng 1.2.x kicker : libpng 1.2.x libpng 1.4.x Oh, what just happened? You say that the ABI collides at run-time and nothing loads .png files anymore?

So, what if we instead make /include/libpng link to /dev/null, and only explicitly install headers into libpng-1.2 and libpng-1.4? Sure! Lets go that way.

kicker now links properly against 1.2 for both. The krita comes along. Krita wants to use a new fancy feature in libpng 1.5. cool. Let's just link that.

Wait. did we just collide the public API again? Crap.

So, in practice. It doesn't work quite as well as hoped. Function resolving when several libraries provide the same function is. Messy. Especially when they aren't perfectly interchangeable.

Why no curl 8

Related Stories