As someone who follows Semantic Versioning like the bible when my API changes I find it incredibly interesting that there is an open source community willing to go about it in such a backwards way. Why wouldn't it be GTK 4.0-ALPHA, GTK 4.0-BETA, GTK 4.0-RTM in which case RTM is the final release that's stable? Why would you release an API as an X.0 that is unstable?
Maybe I'm not as "with it" as I thought with open source communities but I've just never seen this (and I'm sure there are edge cases but GTK is big; seems like something important you'd want to be more stable than not that adheres strictly to semver).
I think I understand it. The X.0 is basically the start of a new technology branch -- it's radically different than what came before which is why it's a new major release. And of course any new radically different piece of software will not be stable, so X.0 represents the most unstable version of this new technology and theoretically X.Y where Y is the latest point release is then likely the most bug free and stable.
Perhaps this makes more sense in a world where software never needs to be finished.
The right way to do version numbers is that the client/caller says "I am complying with version N of the API spec", and the server/callee says "I understand spec versions X through Y at this endpoint". If N < X or N > Y, the transaction is rejected. This applies on a per-endpoint or even a per-function basis, not to the whole system.
If the server gets more functionality, Y can increase. Increasing X breaks some existing programs, but callers which still speak an old version can drop back to that.
The simple explanation is that Semantic Versioning is not at all the only way to do versioning, it is just one standard amongst others. Of course semver is progress in the sense that it has a specification that means you can assign meaning to the versions, but hey, so does the proposed versioning scheme for GTK. It is just not semver.
I think it is interesting to think about what the versioning scheme says about the development model and methodology of the project:
Linux currently uses even-odd versioning, but regardless tries to never break APIs or ABIs
https://en.wikipedia.org/wiki/Linux_kernel#Version_numbering
After much debate, Linux switched from a model where the major number never changed, which is kinda inline with semver. But since this seemed increasingly silly, to have a 3 there forever, they decided to just throw this overboard and start incrementing the version number more often. (This discussion was much more interesting in reality, read LKML for details).
Android uses an interesting brand-version and actually-useful-version scheme (API level)
https://en.wikipedia.org/wiki/Android_version_history
This very much reflects how versioning and releasing a new version has become a PR event. It is really funny how this distinction is even reflected in code.
And then of course there are the funky oddballs:
https://en.wikipedia.org/wiki/TeX
This asymptotically more precise number is suitable for a project that has the idea that it is approaching perfection without changing much. Not sure if every TeX user out there would agree, but it indeed says something about the author =).
There are plenty others, and of course it can be confusing if you think that semver is the only game in town. Perhaps the ideas expressed in the semver spec simple does not suit everyone.
Or if they really need so many minor version numbers before the first stable release, they could do the odd-even thing, where odd major versions are devel and even major versions are stable. So skip to 5.x for the next development cycle, then bump to 6.0 when the API becomes stable. Then 7.x for devel, 8.0 for stable, etc.
In this case: Because it's more fun and personally rewarding to do new stuff, than fight the hard compatibility fight.
In startup API cases: Because it takes 10x longer to build a solid foundation, and you don't yet know whether that's worth it -- time to proof is more important.
And once you have proof, well, you can't change it easily...
And we're still complaining about the very same problems in the very same project.
Edit: God dammit, jwz. Sorry, everybody. Should be safe now, I hope. (I can't see the troll for myself, so I don't know for sure, but if this thing strips the header like it claims to do, that should solve it.)
Startup API cases also often have a chicken & egg situation: you can't know what a good API is until you've had several clients use it, but then you have several clients who will be broken if you change it.
+1 for startup api. It is a bit sad but the same goes for code. It rots really quick and it might not be worth building solid foundations because in next year it will be out of buisness and building solid foundation takes 6 months...
In this case, it's much less responsible to do so. You have people who rely on their software to get things done. Making them jump through hoops like this just leads to frustration, or them abandoning using your program.
The GTK project is hard to understand. They develop with a philosophy that is almost the antithesis of the kernel (which basically says "changes that break programs are bugs"). It would be fine for an application being used directly by end users, but for a library and gui system it is bonkers. I have tried to compile a gtk-based app from source, and had no end of difficulty just because my library release varied by a point-version.
It left a really crummy taste in my mouth.
I really like GTK, and once it's compiled it's great, but these aspects are really painful.
The GTK project basically got taken over by a bunch of Gnome developers who care less and less about non-Gnome users. Many major non-Gnome projects haven't even managed to make the jump to GTK 3 yet (which also seems to be roughly where the project jumped the shark); Firefox only switched a few months ago and GIMP is still thinking about it.
I am so sick of this mentality that seems to raise aesthetic distractions, "new features!!!111", and pointless, frequent version changes over code quality and reusability.
It is a sign that this area of commercial software dev has been almost completely subsumed by marketeers and business hacks; while they may not control GTK (though I honestly don't know/care who does), it is clear that their influence (gotta have the latest new and shiny!) has crowded out other, more prosaic concerns (like stability and compatibility).
A lot can be said about Microsoft's code, but I have always admired just how much effort they go through to preserve API compatibility. (Going so far as to version specific functions and including older versions so as to not break stuff -- TwiddleBit1(), TwiddleBit2(), and so on.
But on another note it's a problem with we programmers as well. We're so distractable... you can see it everyday here on HN... "Show HN" is virtually a graveyard of half-baked, re-hashed ideas implemented in shiny new frameworks. Unicorns trying to take over the world write long-form blog-posts describing their tech (but leaving out enough details to let you try it yourself or duplicate it!) to keep us programmer-types distracted and submissive ('it's better they gawk at code than question our motives') with their pointless show-and-tells.
Also... I am god damn sick and tired of dealing with updates! Stop updating your damn code so much!!!!!!!!!
Or even better... get it right the first time! (It can be done!)
>has been almost completely subsumed by marketeers and business hacks
Welcome to the least common denominator. These business practices serve the masses and raise shareholder value. If we as a society want to change, we should begin to question monetary inflation which openly encourages "shiny and new" investing and "better invest in anything before inflation destroys my life savings". This brand of economics actively pushes people to buy the "brand new" item and invest in the "brand new" startup with no concern for stability or reliability because the hype will raise stockholder value at least in the short term.
This mentality is seeping into every aspect of our society. Without constant updates or new and shiny objects coming out, stock prices plummet. Our entire economy is built on a rotten foundation (unsound monetary policy) which is manipulated to enforce "buy now, ask questions later" economics.
I am actually very excited about this direction for Gtk. If Qt is the stable and serious cross-platform UI library for corporate stuff, why not let GTK be the awesome experimental UI library that breaks everything every 6 months, and keeps pushing the limits on what a free software UI can be? I'm a very happy Gnome 3 user, and I hope they keep pushing to build a usable, simple and pretty user experience, despite the endless stream of this kind of grumpy know-it-all attacks.
Hey, if it was so easy to design an API that is "thought through properly", show us the spec already - there are plenty of hackers around to build it. If it actually worked like that.
Having a more "experimental" project seems like a good idea. But if the API breaks all 6 months, I think it's hard to use such a library unlike your project is a "show HN" style experiment as well that is expected to live only a few months.
After reading the headline, I was actually expecting the article to go in a totally different direction. Most of the time, when I see software with rotten foundations, it's there to preserve backward compatibility. The maintainers all see the rot, they want to fix it, they want to clean it all up, they want to do things right. But they can't do anything that would change the API or break user space in any way, and so, they continue supporting the rot indefinitely.
The alternative of course, is to fix the rot and prioritize long term benefits over short-term pain. The downside is that this could break backwards compatibility. This is the path Python chose when they went from Python 2 -> Python 3, and the resulting schism was so great, that they have promised to never do this again. More often than not, this is the same experience that every software project goes through. Breaking backwards compatibility is so disruptive, that even living with a rotten foundation seems preferable.
Given the blog title, I would have expected that author to argue that fixing the rot is preferable over almost anything else. Instead, he seems to be making the exact opposite argument. He's making the argument that breaking backwards compatibility is so bad, that we should never do it, no matter how rotten the existing API might be.
Of course, he wouldn't actually frame it that way. If you asked the author, he would simply ask "Why can't you just build the API right the first time?" One might as well ask the question: "Why can't you just build a software without any bugs?" Let's see...
1) To err is human and people will make mistakes. Both in implementation (bugs), and in design (bad APIs).
2) Building safeguards against mistakes is expensive, in time and effort. Building 100% robust safeguards against mistakes, is extremely expensive.
3) There's only so much you can learn in a lab, or from a beta. If you don't have any regrets from 2 years of live data, then you haven't learned anything at all.
Every project strikes its own balance along the speed vs stability, and improvement vs backwards-compatibility axis. And there is no intrinsically wrong answer. Just because what your ideal balance differs from the balance that the project chose, is no reason to insult and condescend to them. And yelling at someone for being human and making mistakes, just sounds childish more than anything.
You can have backward compatibility while fixing the foundations. The trick is to add a "compatibility layer" that works well enough for existing clients, then slowly phase it out. Apple in particular is very good at this. They've gone from 68k to PPC, PPC to Intel, "Classic" Mac OS to Carbon to Cocoa, 32-bit to 64-bit, Obj-C to Swift, and so on by maintaining compatibility for old programs on top of new foundations. Unfortunately, these compatibility layers aren't very fun to write and can be difficult to test and maintain, so people (in open source projects especially) tend not to be very interested in the concept.
So apparently you often see the two extremes: Either absolute backwards compatibility with the struggle to preserve every quirk and wrinkle lest clients could break - or "my way or the highway" where you "iterate" the API whenever you feel like it and expect everyone to update.
Is it not possible to find a solid middle ground? E.g. provide different versions of your API in parallel and internally map the old API on the new one. Where that is not possible, iterate the API using a sane timeframe.
I'm not a GTK user, so maybe I'm missing something here. And I certainly agree with the version number complaints. But these quotes trouble me: "what GTK really needs to do is sit down and flesh out a decent API" and "And if you’re having to mess with your API on a continual basis, you’re doing it wrong. Like, the whole software development thing, all wrong."
I think there's an conceptual error here. There are a lot of bad reasons to change software, but I think there are two really good reasons: 1) circumstances change, and 2) we have learned something. Or conversely, I think the only time software can have a static design is when circumstances are static and you never learn anything.
There's this common notion that if people just sit down and think really hard, they will design the perfect thing. That's a mirage. The iPod went through more than a hundred physical revisions before launch. And it has changed a great deal in the 15 years since. Is that because Apple didn't just sit down and think enough? Nope. Even the humble paperclip evolved over decades. If perfect software ever happens, that belongs to a future age.
Here is the rub, if you take a look at the Linux kernel you will see that they have managed, for the most part, to maintain backwards compatibility for a decade or more.
You can probably still run ELF binaries today that you compiled back when they move to the format. Heck, you can even compile the kernel to support a.out of you are so inclined.
Qt maintained binary compatibility from 4.0 in 2005 to 4.8 in 2011, and has from 5.0 in 2012 to 5.7 in 2016. Providing a stable platform is not some impossible ideal. It's a real thing that GTK's competition provides.
I really like that. We are getting closer and closer to having Qt as being the dominating user interface toolkit anyway, and GTK self-destructing can only further this along.
Qt was really stable for last years, indeed Qt 3.x -> Qt 4.x was a painful migration, but they learned their lesson and Qt 4.x -> 5.x was pretty much as smooth as it gets. For simple apps you can mostly migrate from 5.0 all the way up to 5.6 without changing any lines of code.
I like GTK+, but this release schedule horrifies and disgusts me.
If you're going to break the ABI, just increment the number. I get that they want to break the ABI incrementally so that they don't end up with what has become of GTK+ 2.x; where half the applications people use are still on 2.x and so don't have smooth scrolling or new windowing system support.... but I just don't think this is the way to fix that.
Much as I disliked the proposal in the original post (which was later clarified by the GTK+ developers), it is telling that the respondent did not bother to research the reasons behind GTK+'s two API/ABI breaks in its 18 year history.
I have a gtk2 app I built over many years (gtkmm2.4 to be precise) that I have not ported to gtk3. It is a sophisticated app that uses pulgins (webkit, mplayer,
custom, etc). I was thinking maybe I shouldn't spend effort in porting to gtk3. I'm considering going UI free like mpv dose with their video player. Does anyone here have experience in this area and develops plgins for browsers. What are the interesting technologies in this area?
I would laugh about it if I wouldn't have done the same stuff the first time I built something for other people. Do they have a completely new team at gtk dev?
There is a partial solution to this problem- API schemas. Define a schema for your API and make it public, then have API methods auto-generated directly from that. For example, for web APIs, there's jsonschema- http://json-schema.org/ from which you can auto-gen functions in a given language. That way, the parameters around the API such as the URI of an endpoint can be changed from version to version without completely destroying the logic on top of it. It doesn't always solve the problem completely, but it can make it much more tractable.
Include headers /are/ API schemas. The big problem being discussed here is ABI compatibility. Needing to recompile one's software every six months, or have .so.hell is not fun at all.
I was very annoyed by GTK 3.20 wreaking havoc. Firefox scrollbars went missing, until fixed much later (in 48 beta)... I wish they'd just switch to Qt already.
If GTK had the same status in Linux distributions as the Win16/Win32/etc API does in Windows then Linux distributions would carry every API-incompatible version of the library necessary (and maintain old ones).
As it stands, GTK more closely resembles the "Microsoft C++ Redistributable" situation in Windows -- an awkward hybrid of library and API.
> Since when does “X.0” not designate a stable release?
Oh, approximately since Microsoft gained a lead in personal computing in late 1980-something, and decreed that henceforth, systems shall be expected to be a broken mess until version 3.x.
Now I understand the new attraction for KDE with its new plasma release. They script in javascript.
I already quit GNOME with its GNOME 3 iteration desaster. So the fish doesn't only stink at the head, also at its tail. Didn't know that, thanks.
Liked this comment: Well, in the words of my two favorite software dev related quotes:
> ‘How could the wise man build his house on the sand? How could the wise man build his house, where there is no foundation?’ — Eek a Mouse, Noah’s Ark
> ‘The only way a wise man would build his house on the sand is if it was just a hut and he was really high and really enjoyed building new huts.’ — random youtube comment on the above song (sadly I forget who the sage was that wrote that)
[+] [-] BinaryIdiot|9 years ago|reply
Maybe I'm not as "with it" as I thought with open source communities but I've just never seen this (and I'm sure there are edge cases but GTK is big; seems like something important you'd want to be more stable than not that adheres strictly to semver).
[+] [-] wvenable|9 years ago|reply
Perhaps this makes more sense in a world where software never needs to be finished.
[+] [-] Animats|9 years ago|reply
If the server gets more functionality, Y can increase. Increasing X breaks some existing programs, but callers which still speak an old version can drop back to that.
[+] [-] jlundborg|9 years ago|reply
I think it is interesting to think about what the versioning scheme says about the development model and methodology of the project:
Linux currently uses even-odd versioning, but regardless tries to never break APIs or ABIs https://en.wikipedia.org/wiki/Linux_kernel#Version_numbering After much debate, Linux switched from a model where the major number never changed, which is kinda inline with semver. But since this seemed increasingly silly, to have a 3 there forever, they decided to just throw this overboard and start incrementing the version number more often. (This discussion was much more interesting in reality, read LKML for details).
Android uses an interesting brand-version and actually-useful-version scheme (API level) https://en.wikipedia.org/wiki/Android_version_history This very much reflects how versioning and releasing a new version has become a PR event. It is really funny how this distinction is even reflected in code.
And then of course there are the funky oddballs: https://en.wikipedia.org/wiki/TeX This asymptotically more precise number is suitable for a project that has the idea that it is approaching perfection without changing much. Not sure if every TeX user out there would agree, but it indeed says something about the author =).
There are plenty others, and of course it can be confusing if you think that semver is the only game in town. Perhaps the ideas expressed in the semver spec simple does not suit everyone.
[+] [-] rcthompson|9 years ago|reply
[+] [-] audidude|9 years ago|reply
But as for shipping -alpha, -beta, etc, it would also look very weird if GNOME shipped -alpha as a dependency.
[+] [-] jwatte|9 years ago|reply
In startup API cases: Because it takes 10x longer to build a solid foundation, and you don't yet know whether that's worth it -- time to proof is more important. And once you have proof, well, you can't change it easily...
[+] [-] throwanem|9 years ago|reply
Thirteen years ago: https://href.li/?https://www.jwz.org/doc/cadt.html
And we're still complaining about the very same problems in the very same project.
Edit: God dammit, jwz. Sorry, everybody. Should be safe now, I hope. (I can't see the troll for myself, so I don't know for sure, but if this thing strips the header like it claims to do, that should solve it.)
[+] [-] nostrademons|9 years ago|reply
[+] [-] ozim|9 years ago|reply
[+] [-] Sanddancer|9 years ago|reply
[+] [-] _bz2r|9 years ago|reply
It left a really crummy taste in my mouth.
I really like GTK, and once it's compiled it's great, but these aspects are really painful.
[+] [-] makomk|9 years ago|reply
[+] [-] tomc1985|9 years ago|reply
It is a sign that this area of commercial software dev has been almost completely subsumed by marketeers and business hacks; while they may not control GTK (though I honestly don't know/care who does), it is clear that their influence (gotta have the latest new and shiny!) has crowded out other, more prosaic concerns (like stability and compatibility).
A lot can be said about Microsoft's code, but I have always admired just how much effort they go through to preserve API compatibility. (Going so far as to version specific functions and including older versions so as to not break stuff -- TwiddleBit1(), TwiddleBit2(), and so on.
But on another note it's a problem with we programmers as well. We're so distractable... you can see it everyday here on HN... "Show HN" is virtually a graveyard of half-baked, re-hashed ideas implemented in shiny new frameworks. Unicorns trying to take over the world write long-form blog-posts describing their tech (but leaving out enough details to let you try it yourself or duplicate it!) to keep us programmer-types distracted and submissive ('it's better they gawk at code than question our motives') with their pointless show-and-tells.
Also... I am god damn sick and tired of dealing with updates! Stop updating your damn code so much!!!!!!!!!
Or even better... get it right the first time! (It can be done!)
[+] [-] paavokoya|9 years ago|reply
Welcome to the least common denominator. These business practices serve the masses and raise shareholder value. If we as a society want to change, we should begin to question monetary inflation which openly encourages "shiny and new" investing and "better invest in anything before inflation destroys my life savings". This brand of economics actively pushes people to buy the "brand new" item and invest in the "brand new" startup with no concern for stability or reliability because the hype will raise stockholder value at least in the short term.
This mentality is seeping into every aspect of our society. Without constant updates or new and shiny objects coming out, stock prices plummet. Our entire economy is built on a rotten foundation (unsound monetary policy) which is manipulated to enforce "buy now, ask questions later" economics.
[+] [-] tomc1985|9 years ago|reply
[+] [-] ourmandave|9 years ago|reply
[+] [-] jlundborg|9 years ago|reply
Hey, if it was so easy to design an API that is "thought through properly", show us the spec already - there are plenty of hackers around to build it. If it actually worked like that.
[+] [-] xg15|9 years ago|reply
[+] [-] digi_owl|9 years ago|reply
[+] [-] whacker|9 years ago|reply
[+] [-] whack|9 years ago|reply
The alternative of course, is to fix the rot and prioritize long term benefits over short-term pain. The downside is that this could break backwards compatibility. This is the path Python chose when they went from Python 2 -> Python 3, and the resulting schism was so great, that they have promised to never do this again. More often than not, this is the same experience that every software project goes through. Breaking backwards compatibility is so disruptive, that even living with a rotten foundation seems preferable.
Given the blog title, I would have expected that author to argue that fixing the rot is preferable over almost anything else. Instead, he seems to be making the exact opposite argument. He's making the argument that breaking backwards compatibility is so bad, that we should never do it, no matter how rotten the existing API might be.
Of course, he wouldn't actually frame it that way. If you asked the author, he would simply ask "Why can't you just build the API right the first time?" One might as well ask the question: "Why can't you just build a software without any bugs?" Let's see...
1) To err is human and people will make mistakes. Both in implementation (bugs), and in design (bad APIs).
2) Building safeguards against mistakes is expensive, in time and effort. Building 100% robust safeguards against mistakes, is extremely expensive.
3) There's only so much you can learn in a lab, or from a beta. If you don't have any regrets from 2 years of live data, then you haven't learned anything at all.
Every project strikes its own balance along the speed vs stability, and improvement vs backwards-compatibility axis. And there is no intrinsically wrong answer. Just because what your ideal balance differs from the balance that the project chose, is no reason to insult and condescend to them. And yelling at someone for being human and making mistakes, just sounds childish more than anything.
[+] [-] panic|9 years ago|reply
[+] [-] xg15|9 years ago|reply
Is it not possible to find a solid middle ground? E.g. provide different versions of your API in parallel and internally map the old API on the new one. Where that is not possible, iterate the API using a sane timeframe.
[+] [-] wpietri|9 years ago|reply
I think there's an conceptual error here. There are a lot of bad reasons to change software, but I think there are two really good reasons: 1) circumstances change, and 2) we have learned something. Or conversely, I think the only time software can have a static design is when circumstances are static and you never learn anything.
There's this common notion that if people just sit down and think really hard, they will design the perfect thing. That's a mirage. The iPod went through more than a hundred physical revisions before launch. And it has changed a great deal in the 15 years since. Is that because Apple didn't just sit down and think enough? Nope. Even the humble paperclip evolved over decades. If perfect software ever happens, that belongs to a future age.
[+] [-] digi_owl|9 years ago|reply
You can probably still run ELF binaries today that you compiled back when they move to the format. Heck, you can even compile the kernel to support a.out of you are so inclined.
[+] [-] teacup50|9 years ago|reply
Twice.
[+] [-] slavik81|9 years ago|reply
[+] [-] ryanmarsh|9 years ago|reply
Gtk has been around long enough that the boiling should have at least been reduced to a simmer by now.
[+] [-] onli|9 years ago|reply
[+] [-] davidgerard|9 years ago|reply
[+] [-] jkot|9 years ago|reply
[+] [-] kuschku|9 years ago|reply
If they could just use Qt instead... but nooo...
[+] [-] dmytroi|9 years ago|reply
[+] [-] digi_owl|9 years ago|reply
[+] [-] microcolonel|9 years ago|reply
If you're going to break the ABI, just increment the number. I get that they want to break the ABI incrementally so that they don't end up with what has become of GTK+ 2.x; where half the applications people use are still on 2.x and so don't have smooth scrolling or new windowing system support.... but I just don't think this is the way to fix that.
[+] [-] jdub|9 years ago|reply
[+] [-] gato1313|9 years ago|reply
I have a gtk2 app I built over many years (gtkmm2.4 to be precise) that I have not ported to gtk3. It is a sophisticated app that uses pulgins (webkit, mplayer, custom, etc). I was thinking maybe I shouldn't spend effort in porting to gtk3. I'm considering going UI free like mpv dose with their video player. Does anyone here have experience in this area and develops plgins for browsers. What are the interesting technologies in this area?
[+] [-] erikb|9 years ago|reply
[+] [-] scotchmi_st|9 years ago|reply
[+] [-] Sanddancer|9 years ago|reply
[+] [-] shmerl|9 years ago|reply
[+] [-] Filter|9 years ago|reply
As it stands, GTK more closely resembles the "Microsoft C++ Redistributable" situation in Windows -- an awkward hybrid of library and API.
[+] [-] kazinator|9 years ago|reply
Oh, approximately since Microsoft gained a lead in personal computing in late 1980-something, and decreed that henceforth, systems shall be expected to be a broken mess until version 3.x.
[+] [-] rurban|9 years ago|reply
Liked this comment: Well, in the words of my two favorite software dev related quotes:
> ‘How could the wise man build his house on the sand? How could the wise man build his house, where there is no foundation?’ — Eek a Mouse, Noah’s Ark
> ‘The only way a wise man would build his house on the sand is if it was just a hut and he was really high and really enjoyed building new huts.’ — random youtube comment on the above song (sadly I forget who the sage was that wrote that)
[+] [-] Animats|9 years ago|reply
[1] https://www.youtube.com/watch?v=lecHdtywAAU