Originally posted by dkasak
View Post
More Planning Details For GTK4 & Beyond
Collapse
X
-
-
-
Originally posted by boxie View Post
Somewhat. if we look at the kernel and their "Don't Break User Space" mantra we see a completely different side of the coin.
There are many things that can be done to stop a constant churn in ABI breakage, "Not working on it anymore" is just one
Leave a comment:
-
-
Will this new expected fragmentation lead to an increase in resource usage due to having potentially several different versions of GTK loaded for different applications?
Leave a comment:
-
-
Originally posted by MaxToTheMax View PostThis is a problem why? It's exactly the appropriate course of action for anyone who maintains a popular dependency but also wants to do significant new development.
There are many things that can be done to stop a constant churn in ABI breakage, "Not working on it anymore" is just one
Leave a comment:
-
-
Originally posted by Stoatally View PostI left this comment on the blog (it's in moderation):
Maybe I come off as an arse, but really, that versioning scheme is awful.
Using new features available in the current unstable version is largely just asking for pain, so 3rd-party apps will always lag behind. If Gnome has its way, this won't just be a proliferation of GTK versions, but a proliferation of runtimes installed for sandboxed flatpak apps.
Gnome has interpreted "we want a stable api" as "give us a version you'll stop breaki --ahem-- fixing in ways that stop our code from working" rather than "let us use new features without having to deal with unrelated code breaking". I can understand the other side though. It's not fun being restricted from improving your code because people depend on things remaining exactly the same. The GTK2 to GTK3 move was great in that regard especially because of the struct hiding. Struct members were no longer part of the api, so things can change behind the scenes without applications breaking and needing to be recompiled.
It'd probably be rather interesting to see what api changes (rather than just additions) are planned that would make such a transition in development process make sense in the long term. I'd also wonder how hard porting applications would be for each major release.
Leave a comment:
-
-
Originally posted by dkasak View Post
What themes have you built and what changes did you get burned by? Just curious ...
I'm also still waiting to hear about *API* breakages that people have encountered.
Leave a comment:
-
-
Originally posted by bug77 View Post
Oh, good. So theming can continue being the mess that it currently is. I'm glad we got that out of the way.
I'm also still waiting to hear about *API* breakages that people have encountered.
Leave a comment:
-
-
Originally posted by Stoatally View PostI left this comment on the blog (it's in moderation):
Maybe I come off as an arse, but really, that versioning scheme is awful.
Leave a comment:
-
-
I left this comment on the blog (it's in moderation):
As a software developer I believe that if we want to be considered a profession, we have to actually be professional in what we do. A small part of this is versioning our software in an intuitive way and not being afraid to make our lives and the lives of the people who interact with our software (developers, packagers, people reporting bugs and end users) better “just for the sake of it”.
You, I and many others here understand this versioning scheme as it at least has its roots in how other GNOME software is versioned. However it is more complicated and as a result worse than semantic versioning which has clear guidelines on this exact situation.
Please do not make us live with more esoteric versioning.
Leave a comment:
-
Leave a comment: