|
|
Subscribe / Log in / New account

GNOME's new versioning scheme

The GNOME Project has announced a change to its version-numbering scheme; the next release will be "GNOME 40". "After nearly 10 years of 3.x releases, the minor version number is getting unwieldy. It is also exceedingly clear that we're not going to bump the major version because of technological changes in the core platform, like we did for GNOME 2 and 3, and then piling on a major UX change on top of that. Radical technological and design changes are too disruptive for maintainers, users, and developers; we have become pretty good at iterating design and technologies, to the point that the current GNOME platform, UI, and UX are fairly different from what was released with GNOME 3.0, while still following the same design tenets."


From:  Emmanuele Bassi via desktop-devel-list <desktop-devel-list-AT-gnome.org>
To:  Desktop Development List <desktop-devel-list-AT-gnome.org>
Subject:  New GNOME versioning scheme
Date:  Wed, 16 Sep 2020 16:02:50 +0100
Message-ID:  <CALnHYQHkU9KzLnoYj1HnEq-+Hc4k4G_0fjHVcNixPME6CBLFyQ@mail.gmail.com>
Cc:  gtk-app-devel-list list <gtk-app-devel-list-AT-gnome.org>, distributor-list-AT-gnome.org
Archive-link:  Article

Hi all;

This email is cross-posted to Discourse:

  https://discourse.gnome.org/t/new-gnome-versioning-scheme...

Please, use Discourse to ask further questions or clarifications.

After various off-line/in person talks, last year I started [a
discussion][0] on Discourse about the existing version scheme of GNOME.
[This topic][1] was also raised in July, and discussed at the release team
meeting during GUADEC. Now that the GNOME 3.37 development cycle is over,
and 3.38 is out of the door, it's time to draw this issue to its conclusion.

In the interest of clarity, I'll present the conclusion first, and then try
to answer common questions. The questions summarise the feedback and
iterations of the change; feel free to read the whole topic on Discourse if
you wish to understand what led to the final form of this change.

## The new GNOME versioning scheme

The next version of GNOME, due to be released in March 2021, will be GNOME
40.

The GNOME 40 development cycle will have three releases:

 - 40.alpha
 - 40.beta
 - 40.rc

Followed by the first stable release, 40.0. Every subsequent stable release
will increment the minor component by 1, so:

 - 40.1, 40.2, 40.3, …

After the 40.0 release in March 2021, the next version of GNOME will be 41,
and will follow the exact same pattern.

To recap:

 - the new versioning scheme starts at 40
 - each new development cycle will increment the version by 1
 - each development cycle will have three releases: alpha, beta, rc
(release candidate)
 - the first stable release will have a minor version of 0
 - each stable release will increment the minor version by 1

## Adopting the new versioning scheme

The new version will be visible in the following components:

 - the "GNOME version" field of the "About" section in GNOME Control Center
 - the version of GNOME in the Tour application
 - the application version in the "About" dialog of core GNOME applications

Additionally, the version of the SDK and Platform run times will follow the
same versioning scheme, so you will depend on, for instance,
org.gnome.Platform//40.

If you maintain an application that is not in the list above, then you can
keep following your own versioning scheme.

Libraries in the platform are not expected to change their existing
versioning scheme, but they are still expected to follow the release
cadence of GNOME, with *at least* an alpha, beta, and rc releases.

If your GNOME core application provides an API—for instance, for
plugins—you can version the programming interface however you prefer, as
long as the user visible version of the application follows the GNOME
scheme.

## Frequently Asked Questions

Q: Why do we need a new versioning scheme?
A: After nearly 10 years of 3.x releases, the minor version number is
getting unwieldy. It is also exceedingly clear that we're not going to bump
the major version because of technological changes in the core platform,
like we did for GNOME 2 and 3, and then piling on a major UX change on top
of that. Radical technological and design changes are too disruptive for
maintainers, users, and developers; we have become pretty good at iterating
design and technologies, to the point that the current GNOME platform, UI,
and UX are fairly different from what was released with GNOME 3.0, while
still following the same design tenets.

Q: Why start at 40?
A: Because the next version would be 3.40, and it's a nice, round number.
The 3.38 release was the 40th release of GNOME, but this discussion came
too late in the cycle to effectively switch, so we can say that, if you
start counting at zero, the next cycle would be the 40th release of GNOME.
By using 40 as the base, we acknowledge what came before, and we don't
introduce a large discontinuity in the number progression, which is
somewhat the point of this change.

Q: Why not 4.0?
A: With GTK 4.0 being released during the next development cycle, calling
the next version of GNOME "4.0" would have unfortunate/unintended
implications about the platform, especially from an engagement and
marketing perspective. We want to decouple GNOME from deep changes in the
application development platform, so that GTK can be released more often,
and [provide "long term support" major versions][2], instead of delaying
development cycles that inevitably end up into "rewrite the world" events.
GNOME is not just a technological platform, but also a set of design
guidelines and an [ethos][3], and bumping the major version along with GTK
does not reflect that.

Q: Why not using the year/month scheme?
A: While date-based versioning schemes do make it easier to resolve the
issues of "when was this version of GNOME released" and "how old is my
version of GNOME compared to the latest one", they still rely on knowing
that the version number is, indeed, date based. Even the "gold standard" of
date-based releases, Ubuntu, has users confused about the version numbers,
as outlined in multiple topics on different user support forums.
Additionally, a date-based versioning scheme requires on a twice-per-year
schedule, with stable releases that continue over the span of a year each,
introduces possible collisions and uncertainty, unless more numeric
components are added, thus making version numbers more complicated.

Q: What happened to even/odd (or "Linux kernel style") versions?
A: Just like the Linux kernel, we found that there's no real advantage in
an even/odd split any more. Not many people actually use the odd-numbered
versions of GNOME, even when distributions package them. From the
perspective of application developers, especially with the advent of
bundling technologies like Flatpak, you will either use the bleeding edge
"nightly" snapshots, or, more likely, you'll use the current stable run
times until you are ready to update them.

Q: Why only three development releases?
A: With the advent of nightly builds and continuous integration and
delivery pipelines, there's no real advantage in having multiple alpha and
beta snapshots any more, considering the amount of people actually using
them outside of GNOME maintainers (and the odd packager); they are mostly
busy work for the release team, at this point. Maintainers do tend to skip
the alpha releases, and having more releases in the beta/release candidate
period usually injects more stress into the development process.
Nevertheless, if maintainers wish to do multiple releases, they are
absolutely free to do so. The release team will guarantee those three
development releases for the whole of GNOME.

Q: Does this versioning scheme apply to every GNOME project?
A: The intended audience for this versioning scheme is GNOME users.
Libraries have difference constraints, and thus do not need to conform to
it, and neither do applications that are not in the core applications set,
as defined by the release team. Maintainers are free to follow the same
scheme, or adopt their own. Some applications expose a programmable
interface for out of tree plugins; the interface can have its own
versioning scheme, or it can follow the version of the application.

Q: What about packaging development releases of GNOME? How do we deal with
the new versions?
A: Since packaging rules vary from distribution to distribution, and from
packaging format to packaging format, it is left to the downstream
packagers's judgement how to translate the "dot-alpha", "dot-beta", and
"dot-rc" versions into something that can be appropriately represented by
their downstream project. If the packaging rules or format do not allow
alphabetic components, or do not sort alphabetic components before numeric
ones, we recommend using something like:

 - .0alpha, .0beta, .0rc
 - .0~alpha, .0~beta, .0~rc
 - .0a, .0b, .0rc

which should sort in the correct order, and do so before the .0, .1, … of
the stable releases.

Q: How does this scheme impact the branch naming when opening a new
development cycle?
A: The stable branches will keep the same policy, "gnome-" + version; so
you will have "gnome-40", "gnome-41", and so on, and so forth.

Q: What version number should I use between the latest stable release and
the new development cycle?
A: You should use the version of the next stable, plus the "alpha"
component. Once you cut the alpha release, you update to "beta"; once you
cut the beta release, you update to "rc"; once you cut the release
candidate, you update to 0.

Q: Can I make additional alpha/beta/rc releases? How do I call them?
A: Of course you can do more releases, if you want to; you can use a scheme
such as:

 - .alpha.0, alpha.1, …
 - .beta.0, beta.1, …
 - .rc.0, .rc.1, …

to distinguish them.

Q: I do pre-release version bumps; what do I do, now?
A: The preferred model is to move to post-release version bumps. In other
words: you change the version of your project *after* cutting a release.
For instance, a typical development cycle might look like this:

 - you just released "40.0" (first stable release)
   - open the development cycle for GNOME 41
   - create the `gnome-40` branch
   - bump the version of your project to "41.alpha" in your development
branch
   - commit the change
 - hack, hack, hack
 - release "41.alpha"
   - update the `NEWS` file
   - commit the change
   - tag the commit
 - bump the version of your project to "41.beta"
 - commit the change
 - hack, hack, hack
 - release "41.beta"
   - update the `NEWS` file
   - commit the change
   - tag the commit
 - bump the version of your project to "41.rc"
 - commit the change
 - we are in freeze, so hack with caution
 - release "41.rc"
   - update the `NEWS` file
   - commit the change
   - tag the commit
 - we are now in hard code freeze, so no hacking
 - release "41.0"

This is a change that might take a bit of an adjustment, but we feel it's
the best compromise towards a consistent versioning behavior.

Q: This is nonsensical. Why do you want to change the versioning scheme at
all? It's just numbers!
A: Numbers, like words, have meaning, and tell a story. With a change in
the versioning scheme we wish to communicate the fact that GNOME doesn't
see major versions of the development platform as the driving force behind
major changes in its user experience; and that radical changes to the user
experience are going to be introduced progressively, so that we can refine
and iterate over them in time, instead of dumping them in our users lap.

## Additional questions

Feel free to discuss this topic on Discourse, and to reach out to the
release team for additional clarifications.

On behalf of the GNOME release team,
 Emmanuele Bassi

[0]:
https://discourse.gnome.org/t/straw-man-proposal-changing...
[1]:
https://mail.gnome.org/archives/desktop-devel-list/2020-J...
[2]:
https://blog.gtk.org/2016/09/01/versioning-and-long-term-...
[3]: https://blogs.gnome.org/aday/2017/08/08/the-gnome-way/

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list


to post comments

GNOME's new versioning scheme

Posted Sep 17, 2020 21:57 UTC (Thu) by nix (subscriber, #2304) [Link] (38 responses)

So "the minor version number is getting unwieldy", but the fix is to use *the exact same number* for the major version number, so presumably that's not unwieldy? What is it about following a period that makes 38 an unwieldy number, where 40 before a period is not?!

I know other software has done the exact same thing (Emacs being the major one I can think of), and "the minor version number is too big" is almost the only rationale ever used for bumping the kernel's major version number... but that rationale still makes no sense at all to me. Of course version numbers are totally arbitrary as long as they always go up, and it's not like we're going to run out of integers, but, still, this feels to me like wheel-spinning, change for change's sake.

(Libraries in the platform have still not finished renumbering themselves to 3.x -- another few renumber every new GNOME release -- so it's a good thing all the libraries don't need to renumber again. On past form it'd be 2035 before they were all finished.)

GNOME's new versioning scheme

Posted Sep 17, 2020 22:28 UTC (Thu) by ebassi (subscriber, #54855) [Link] (19 responses)

> So "the minor version number is getting unwieldy", but the fix is to use *the exact same number* for the major version number, so presumably that's not unwieldy? What is it about following a period that makes 38 an unwieldy number, where 40 before a period is not?!

The problem is not the number in and of itself, but the fact that it's following another number, and that creates expectations. If you see "3.large-number", you'll be tempted to ask "when are we going to move to 4.0?", especially since the 1.x series stopped at 4, and the 2.x series stopped at 32.

The whole point of dropping the current major version is to say: we are not going to do major versions any more. The core toolkit can bump up its API version without causing a massive change in the platform, such that we have to stop and port everything; and the UX can change iteratively as well.

GNOME's new versioning scheme

Posted Sep 18, 2020 9:00 UTC (Fri) by geert (subscriber, #98403) [Link] (1 responses)

> If you see "3.large-number", you'll be tempted to ask "when are we going to move to 4.0?"

Which is exactly the opposite of what the phone vendors are doing wr.t. Linux: don't move to the next major version, move to the next minor (LTS) version instead, perpetually.

GNOME's new versioning scheme

Posted Sep 22, 2020 22:55 UTC (Tue) by khim (subscriber, #9252) [Link]

> That's because they are not in the business of selling you Linux kernel.

When they *do* want to sell you something... S20 follows S10 because S11 would be too small of an update.

So Linus did that right: by bumping kernel version occasionally (even if arbitrarily) it makes these numbers interesting for Joe Average. Who can count to ten, sometimes, but it's "number too large to care" after that.

GNOME's new versioning scheme

Posted Sep 18, 2020 13:25 UTC (Fri) by nix (subscriber, #2304) [Link] (16 responses)

Makes sense. Feels like you might be setting yourself up for problems in the future, though: what if, in ten years, you realise that in fact you *do* want a new major version for the holographic telepathic GNOME release? You can't add a major number back on without a lot of trouble.

I guess the only possibility there would be renaming the project as a whole :( I suppose if any change you can envision is so large that it would be tantamount to a whole new project, this might still be the right thing to do.

(I certainly did expect that the ports of packages to Gtk 4 would be such a step change, particularly given that it seems likely to need to happen to all libraries in the framework simultaneously as long as they might get loaded into the same process, but apparently not? I suppose, if anyone knows if that's true it would be you, so nobody *other* than you can safely make this determination :) )

GNOME's new versioning scheme

Posted Sep 18, 2020 15:30 UTC (Fri) by ebassi (subscriber, #54855) [Link] (15 responses)

> what if, in ten years, you realise that in fact you *do* want a new major version

We'll burn that bridge when we cross it.

Though, again, the only thing that would warrant a major release is a complete overhaul of our HIG to use holograms and telepathic input, dropping any other input and output method. Short of that, an incremental approach will always be preferred.

> I certainly did expect that the ports of packages to Gtk 4 would be such a step change

Releasing GTK4 will require API bumps in other libraries, indeed; but we do have strong parallel installability guarantees for a reason, and we can phase out the GTK3 reverse dependencies in time. GTK3 is still supported, and so will be the libraries that depend on it; once all the libraries used by an application have been updated to support GTK4, porting your application should not require a major step.

Even if GTK4 is a fair amount of rework of the internals of the API, though, it's not like GTK4 widgets have suddenly become entirely different from GTK3 in appearance and behaviour; a GTK4 application side by side with a GTK3 one will look and behave in a fairly similar fashion; and once GTK4 is out, everything will be frozen, so at most we expect visual refreshes (and maybe some new widget), like we do for GTK3.

The reason why GTK2 and GTK3 were a fair amount of work such that they required bumping the whole UX of GNOME was that both deprecated large swaths of the application development platform, or introduced new API at the bottom of the stack—below GTK itself. We've consolidated various functionality inside GTK4, and these days you only have libraries that provide you with additional, ad hoc widgets—like libhandy, for supporting multiple form factors; or GtkSourceView, for code editing; or WebKitGTK, for embedding web content. Once those libraries get ported (and they are in the process of being ported), most GNOME applications will be able to move to GTK4 on their schedule, instead of a mad rush to get everything sorted in 6 months.

GNOME's new versioning scheme

Posted Sep 18, 2020 19:48 UTC (Fri) by nix (subscriber, #2304) [Link] (14 responses)

Releasing GTK4 will require API bumps in other libraries, indeed; but we do have strong parallel installability guarantees for a reason, and we can phase out the GTK3 reverse dependencies in time. GTK3 is still supported, and so will be the libraries that depend on it; once all the libraries used by an application have been updated to support GTK4, porting your application should not require a major step.
Oh dear. Unless you've changed every public symbol name in Gtk 4, this will fail: the moment one library is ported to use Gtk 4, even if it bumps soname and gains parallel installability at the same time, any process that depends directly or transitively on both that library and Gtk 3 will suffer symbol name clashes between the two Gtks, a pile of unintended interposition, and likely disaster (so this also happens if you port any application to Gtk 4, if any of its libs still uses Gtk 3, and vice versa). You can hack around this to some degree using -Bsymbolic and DT_GROUP, but this is a) ELF-specific and b) won't help with data structures passed between the incompatible Gtks: so you probably have to change the names of all datatypes in the public API as well. Worse yet, this also applies to non-GNOME users of Gtk, so you can never be sure this won't trip you up.

This sort of thing caused a number of problems for distros in the Gtk 2 transition period and is probably one reason why packagers and distributors groaned at the new plan of breaking the Gtk ABI more frequently. ABI breakage hurts. I think glibc and the X libraries have the right of it here: widely-used libraries should never, ever break ABI at all, for any reason. Yes, this makes library design really hard: blame ELF :(

(You probably know all this already and have planned for it, though it's a hell of a lot of work and honestly I'm not sure how you can make it less than horrendously painful for everyone: I'm just posting this in case you overlooked this particular pile of festering nightmares and the degree to which it hurts all your direct and indirect library users. It's amazing how many major projects overlook it: GhostScript is one, which forked libcms into a multithread-capable version for internal gs use without changing any of the symbol names, so now any libcms users which also include libgs are likely to dump core. The only solution to that is to not use the gs fork of libcms, which is explicitly unsupported and planned to go away. I guess that means libgs users that want to do colour management are all screwed when that happens. Sigh.)

GNOME's new versioning scheme

Posted Sep 19, 2020 1:15 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (6 responses)

I think, but may be wrong, that other formats (Mach-O and PE mainly) actually have facilities to bind to symbols in given libraries, so collisions there are actually "okay" since you also look up symbols through a library name filter. I do wish ELF didn't do the "one big bag of symbols" approach, but we're stuck with that I guess. I suppose you could mitigate it with symbol versioning to differentiate between libgtk3 and libgtk4, but that's not always easier and the entire ecosystem would probably need to do it.

And yes, embedding libraries is a real pain. We do it because we have Windows and macOS deployments and who is going to have a viable HDF5 SDK just laying around there? No one, that's who. But I make sure that every library name, header file, and exported symbol is mangled to avoid conflicts. Sometimes static globals still bite us, but those errors usually have the symbol name in them so we can go and fix it. We don't mangle data types because no one should be including our mangled library and a real one in the same TU anyways. Alas, Python module paths/names are also nigh impossible to mangle in practice, so we do end up colliding there, but AFAIK, there's nothing we can do about that.

GNOME's new versioning scheme

Posted Sep 19, 2020 11:40 UTC (Sat) by nix (subscriber, #2304) [Link] (5 responses)

This is what the combination of -Bsymbolic (to bind to the locally-visible definitions at link time and avoid interposition: -z now might help too) and DT_GROUP (to prevent the locally-used Gtk from "leaking out" to supervening libraries) is meant to do. I'm not entirely sure it works 100%: I know glibc has historically had painful-to-even-describe bugs in this area. Still, in the absence of a working dlmopen (which is an even *bigger* pile of pain to use even when it does work), or renaming all symbols and publically-visible types (even worse!) this is the best we can do. It is not a very good best.

GNOME's new versioning scheme

Posted Sep 19, 2020 18:46 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (4 responses)

Hmm, my reading of the flags is as such:

- -Bsymbolic: don't look for symbols we know are in our own library anywhere else

So this doesn't seem like it would help with other code using my symbols from getting confused. Do you have documentation links for DT_GROUP? My manpages have nothing about it. From your descriptions, it sounds like it restricts symbol lookups to those found via DT_NEEDED for the library itself? So basically, a better `RTLD_LOCAL`. How does this interact with weak symbols (like, say, Anaconda where libpython.so symbols are meant to be provided by the loading executable)?

GNOME's new versioning scheme

Posted Sep 19, 2020 19:24 UTC (Sat) by nix (subscriber, #2304) [Link] (3 responses)

-Bsymbolic applied to (say) the link of Gtk 4 itself stops Gtk's own internal calls to its own symbols from being interposed by some other Gtk that happened to have been loaded earlier.

DF_GROUP (as usual I got this one wrong, it's a flag, not a tag) constrains symbol searches from within this library to happen only within the library and its transitive DT_NEEDED libraries: it stops global symbols or symbols in other branches of the search tree from interposing. The relevant ld flag to look for is '-Bgroup'. It is *not* the same as --start-group/--end-group or the linker script GROUP command: fairly confusing naming really. Weak symbols still work, but only if they're resolved by objects loaded by this shared library or things it loaded. (So the old pthreads trick wouldn't work, not that it's a good idea anyway in glibc 2.32+.)

GNOME's new versioning scheme

Posted Sep 22, 2020 16:33 UTC (Tue) by mathstuf (subscriber, #69389) [Link] (2 responses)

Hrm. The fact that it is a library-wide flag works most of the time, but really fails for plugins. I'd like them to load their novel dependencies directly, but those from the loading application usually should just be expected to be there. Maybe `--warn-unresolved-symbols` can help to alleviate that though.

I have a PR (that's likely fallen on deaf ears) for macOS' linker to have a "any symbol you find in this library should be looked up at runtime" behavior which is, I think, exactly the kind of behavior I'd like. https://github.com/apple-opensource/ld64/pull/1

For reference, the search term to use for the ELF flag is `DF_1_GROUP`.

GNOME's new versioning scheme

Posted Sep 22, 2020 21:38 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

I don't know what "looked up at runtime" means: all symbols in dynamically-linked programs are looked up at runtime, that's what dynamic linking *is*. Perhaps you mean "look for these symbols in the main program"? Because if so, that's the ELF default: the search scope for all symbols starts with the main program and goes on from there. (Well, OK, actually it starts with ld.so itself, and the main program comes right after that, usually followed by libc.)

GNOME's new versioning scheme

Posted Sep 22, 2020 21:54 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

As opposed to getting "this symbol was not found" errors at link time. So if I use `-Bgroup`, symbols will be searched for in the loading chain and then *only* the DT_NEEDED libraries? Or does the library/executable providing a plugin API also need to be in the DT_NEEDED section for DF_1_GROUP to work appropriately?

GNOME's new versioning scheme

Posted Sep 19, 2020 3:04 UTC (Sat) by pabs (subscriber, #43278) [Link] (4 responses)

Does GTK not use symbol versioning?

GNOME's new versioning scheme

Posted Sep 19, 2020 11:32 UTC (Sat) by smcv (subscriber, #53363) [Link] (3 responses)

No, GTK doesn't have versioned symbols.

Versioned symbols have two main uses: disambiguating between incompatible SONAMEs of the same library (which is the use you have in mind here), and keeping track of which version is required.

In the GObject world, versioned symbols are not useful for the first of those uses, because the GObject type registry is a flat global namespace that is basically a hash table in libgobject-2.0.so.0, a library that hasn't broken ABI for something like 20 years. So you'd still have the same collisions with versioned symbols, but instead of being over which version of gtk_widget_activate() is the right one to find in ELF symbol lookup, they'd be over which version of g_type_from_name("GtkWidget") is the right one to find in GObject type lookup.

GObject could in principle gain a concept of versioned type-names analogous to versioned symbols, and people have experimented with doing just that, but that would likely lead to an API and ABI break throughout the GLib-based stack, which conflicts with the fact that GLib/GObject is effectively following the glibc model for ABI compatibility (i.e. don't break ABI, ever). A SONAME bump in GObject would force every GObject-dependent library to also change its SONAME (or crash a lot, I suppose, but let's not go there). You might think moving from GTK 2 to 3 (and in future to 4) has already been a disruptive transition, but moving from GObject 2 to 3 would also involve non-GUI libraries, and lower-level-than-GTK GUI libraries like GDK-Pixbuf and Pango. That's a major reason why GLib/GObject didn't break ABI in GNOME 3.

Versioned symbols can still be useful in GObject-based libraries whose namespace conventions collide with a non-GObject library (for example json-glib, json-c and jansson, which unfortunately all use json_*), and they can still be useful to track when symbols where introduced (for example in telepathy-glib), but neither of those is immediately relevant here.

GNOME's new versioning scheme

Posted Sep 19, 2020 11:44 UTC (Sat) by nix (subscriber, #2304) [Link] (2 responses)

GObject could in principle gain a concept of versioned type-names analogous to versioned symbols
I'm wondering if you could do that by adding a g_mangle_name() with which you could say g_mangle_name("GtkWidget", 2, 0) and get back GtkWidget@2 (the 0 is a minor number): equally you could unmangle it to find that the version of GtkWidget@2 was 2, etc. As long as version 1 had an unmangled name, it seems to me you could bring this in without disrupting existing users of (necessarily unmangled) GObject names at all, and *certainly* without the horror show which would be breaking glib's ABI.

I didn't sleep well last night so probably there is some really obvious reason why this wouldn't work which I just can't identify right now.

(... and now I'm wondering if CTF could help fix the type side of this. Alas, probably not, not unless we augment CTF with version info *and* ld.so starts using it somehow. Which is a possibility for the distant future, hmmm... another reason for me to come up with the do-less-mallocs version of libctf, since ld.so's early-operation malloc is so crude it's best to avoid doing complex patterns of temporary allocations in it.)

GNOME's new versioning scheme

Posted Sep 21, 2020 14:02 UTC (Mon) by smcv (subscriber, #53363) [Link] (1 responses)

> I'm wondering if you could do that by adding a g_mangle_name() with which you could say g_mangle_name("GtkWidget", 2, 0) and get back GtkWidget@2 (the 0 is a minor number)

This is more or less how the experiments that were done in the past worked (I think they might have just hard-coded the name-mangling as a proof of concept, but that's an implementation detail).

> As long as version 1 had an unmangled name, it seems to me you could bring this in without disrupting existing users of (necessarily unmangled) GObject names

For *some* users, yes. The experiments I saw were on GTK 2/3 compatibility (back when GTK 2 was still maintained) so they assumed that significant changes to GTK 2 and GTK 3 source code wouldn't be allowed, and they also made the simplifying assumption that the versioned naming would have to apply globally, to all GObject libraries; but you're right to say that continuing to use the simple names for existing libraries, and only bringing in the versioned names on an opt-in basis for new SONAMEs, would be a migration strategy less likely to cause regressions.

It might already be too late for that in GTK 4, but perhaps it's viable for GTK 5, or for the next time Evolution breaks ABI.

For GObject users that have to be able to deal with unknown types generically, I could see the mangled names still causing breakage: for example if code generation tools like Vala assume that the type named "GtkWidget" is a "GtkWidget *" in C source code, that assumption will no longer hold. (But it already wasn't true for some particularly creative/evil/broken GObject libraries, like dbus-glib with its parameterized types.)

GNOME's new versioning scheme

Posted Sep 21, 2020 14:30 UTC (Mon) by nix (subscriber, #2304) [Link]

> For GObject users that have to be able to deal with unknown types generically, I could see the mangled names still causing breakage: for example if code generation tools like Vala assume that the type named "GtkWidget" is a "GtkWidget *" in C source code, that assumption will no longer hold. (But it already wasn't true for some particularly creative/evil/broken GObject libraries, like dbus-glib with its parameterized types.)

Yeah, some things would definitely need adjusting to know that mangling was *possible*. (This was, of course, true when ELF gained symbol versioning, too: some things needed to know what the @ and @@ in symbol names meant. But most things didn't need to know at all.)

GNOME's new versioning scheme

Posted Sep 19, 2020 13:00 UTC (Sat) by ebassi (subscriber, #54855) [Link] (1 responses)

> any process that depends directly or transitively on both that library and Gtk 3 will suffer symbol name clashes between the two Gtks, a pile of unintended interposition, and likely disaster (so this also happens if you port any application to Gtk 4, if any of its libs still uses Gtk 3, and vice versa)

Yes, we know. That's why you cannot load different versions of GTK in the same process; as soon as you do, you will hit an assertion failure, and since initialising GTK must be the first thing that you do, it'll happen pretty much instantaneously.

It's not our first rodeo.

GNOME's new versioning scheme

Posted Sep 19, 2020 14:15 UTC (Sat) by nix (subscriber, #2304) [Link]

Oh good! In hindsight I have dim memories of hitting this, but it was so long ago I'd forgotten.

GNOME's new versioning scheme

Posted Sep 17, 2020 23:43 UTC (Thu) by flussence (guest, #85566) [Link] (17 responses)

>What is it about following a period that makes 38 an unwieldy number, where 40 before a period is not?!

I guess it's easier to shed the masive stigma of "GNOME 3" by simply rendering it impossible to correlate public perception to versioning, than to address the root cause of that public perception.

Worked for Mozilla, which as we can see is a flourishing and healthy corporation with no problems whatsoever.

GNOME's new versioning scheme

Posted Sep 18, 2020 3:40 UTC (Fri) by rsidd (subscriber, #2582) [Link] (15 responses)

> Worked for Mozilla, which as we can see is a flourishing and healthy corporation with no problems whatsoever.
Sounds like you're being sarcastic, but in fact Mozilla is providing us
  • the only web engine alternative to Webkit/Chromium (now that even Microsoft has switched to the latter); and it works on essentially everything, which is an incredible achievement. I use Firefox on both mobile and desktop, except for MS Teams video (for some reason that doesn't support firefox; I don't think there is any technically valid reason). Today the browser engine is essentially an operating system in its own right (as ChromeOS shows us) and what Mozilla does is give us a nearly 100% compatible reimplementation of the same OS. That's important for many many reasons.
  • one of the few exciting programming languages to come out in recent years, Rust, probably the only successful modern language targeted at the C/systems-programming crowd.
And Mozilla is surviving, I would say flourishing among people who matter.

GNOME's new versioning scheme

Posted Sep 18, 2020 6:19 UTC (Fri) by flussence (guest, #85566) [Link] (8 responses)

>I use Firefox on both mobile and desktop, except for MS Teams video (for some reason that doesn't support firefox; I don't think there is any technically valid reason)
Might be the same reason Jitsi Meet doesn't work on Firefox?

Rust hasn't been under Mozilla's umbrella for a while (the project lead resigned not long after that whole Looking Glass thing) and they recently sacked a whole lot of important side-project Rust devs.

GNOME's new versioning scheme

Posted Sep 18, 2020 10:21 UTC (Fri) by rsidd (subscriber, #2582) [Link]

Jitsi does work with Firefox, for a while now. Interestingly, last I checked, on linux Cisco Webex worked *only* with firefox.

GNOME's new versioning scheme

Posted Sep 18, 2020 11:08 UTC (Fri) by LtWorf (subscriber, #124958) [Link]

Works for me on firefox.

GNOME's new versioning scheme

Posted Sep 19, 2020 3:00 UTC (Sat) by pabs (subscriber, #43278) [Link] (3 responses)

Got any links about the Looking Glass thing? I hadn't heard about it.

GNOME's new versioning scheme

Posted Sep 19, 2020 12:10 UTC (Sat) by farnz (subscriber, #17727) [Link] (2 responses)

The official Looking Glass retrospective is online - it was a tie-in with the "Mr Robot" TV show, and they used their experiments platform to install an add-on for all users:

Instead of giving users the choice to install this add-on, we initially pushed an update to Firefox that installed the “Looking Glass” add-on for English speaking users. This add-on was installed and set to ‘OFF’ and made no changes in the user experience unless it was explicitly turned on by a user, but it was added. Even when turned on no user data was collected or shared

GNOME's new versioning scheme

Posted Sep 19, 2020 15:31 UTC (Sat) by rsidd (subscriber, #2582) [Link] (1 responses)

Back in 2014 Apple pushed U2's album Songs of Innocence to all iTunes users worldwide. The album did not auto-play and made no changes in the user experience, but it was added. Even when played no user data was collected or shared. Nevertheless it was widely panned as a terrible stunt and Bono apologized. Pity Mozilla didn't learn from that!

GNOME's new versioning scheme

Posted Sep 19, 2020 20:58 UTC (Sat) by Wol (subscriber, #4433) [Link]

Now Windows 10 regularly pushes games and other stuff like that into installs. I just wish someone would pan them for it and tell them not too ...

Hint - I DON'T PLAY GAMES !!! (or only one or two that is - AOE Age of Empires and Kpat). (And probably not AOE much longer as it's an XP install that is likely to break in the near future.)

Cheers,
Wol

Firefox, Teams, Jitsi Meet

Posted Sep 25, 2020 14:08 UTC (Fri) by robbe (guest, #16131) [Link] (1 responses)

> Might be the same reason Jitsi Meet doesn't work on Firefox?

Looks like this is fixed with FF 80.

For MS Teams, support for non-Chromium browsers seems to be low priority. Their focus clearly is on the (Electron) app, and Chromium support kind-of emerges for free out of that.

Firefox, Teams, Jitsi Meet

Posted Sep 25, 2020 14:59 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Hmm. I was using Jitsi in Firefox as far back as May, so it was working at least there. I think it was even working with the pile of add-ons I use.

GNOME's new versioning scheme

Posted Sep 18, 2020 12:06 UTC (Fri) by Conan_Kudo (subscriber, #103240) [Link] (5 responses)

And Mozilla is surviving, I would say flourishing among people who matter.

This is absolutely not true. If anything, Mozilla is slowly dying. They just killed another pair of products today: Firefox Send and Firefox Notes.

They are hemorrhaging people, both voluntarily and involuntarily. Their share in the marketplace is dwindling rapidly. And they're unable to keep up with the development of web standards to the point that people are forced to use Google Chrome to visit websites and expect things to work.

That is not not the mark of a flourishing company. That is the mark of an increasingly irrelevant company. And as someone who values Firefox and work Mozilla does, that's deeply disheartening and depressing.

GNOME's new versioning scheme

Posted Sep 18, 2020 13:01 UTC (Fri) by rsidd (subscriber, #2582) [Link]

In terms of chrome compatibility, they are very close. As other comments on this thread note, firefox works with most videoconferencing software. (I used it the other day with bluejeans, which did not support it a month or so ago). In terms of marketshare, it's comparable to Safari and more than IE and Edge combined, which is remarkable given that those browsers come pre-installed with their OS (and Chrome usually comes pre-installed with Android).

Yes, their financial and other difficulties are a worry. But they have been around for a long time, they will survive.

GNOME's new versioning scheme

Posted Sep 22, 2020 23:16 UTC (Tue) by khim (subscriber, #9252) [Link] (3 responses)

I'm not really sure that's Firefox fault, though.

Yes, I know that Chrome still adds crap at breakneck pace... but when was something added that actually improved experience of the end user? I would say that was probably Webrtc. It made something which was impossible before... possible. That was almost 10 years ago.

Everything after that? Mostly a way to make marketing guys happy by adding useless bells and whistles which only suck bandwidth, CPU and Memory without providing anything meaningful in return.

Google is now the master of EEE strategy which, naturally, kills everything else. Just like it happened when Microsoft did that.

GNOME's new versioning scheme

Posted Sep 23, 2020 9:02 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

I think webauthn was also useful. (Less so the security horror of WebUSB that it uses.)

GNOME's new versioning scheme

Posted Sep 24, 2020 12:07 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

What exactly do you get from it that wasn't possible with U2F? Why exactly do you need that? Heck, why must U2F be part of the browser, anyway? Why couldn't be that just a plugin like quarter-century ago?

Oh, right, Mozilla and Google foolishly (well... foolishly on Mozilla side... Google knew what it did) killed it, so now we have no choice but to add everything including kitchen sink to the browser...

Not convinced, sorry.

GNOME's new versioning scheme

Posted Sep 24, 2020 12:32 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, when I said 'webauthn' I really meant 'U2F and its successor webauthn'. Both are much newer than the cutoff date :)

(And... well, yeah, it could be a plugin, but plugins are a security nightmare themselves and usually much harder to both keep working and audit than something that's part of the browser to start with: and the interface between the plugins and the browser would need revising before that would work in any case, and if you're doing that, why not just build in U2F support? In practice by the time U2F got going nobody wanted to write new plugins if they had any alternative...)

GNOME's new versioning scheme

Posted Sep 18, 2020 7:58 UTC (Fri) by ibukanov (subscriber, #3942) [Link]

Firefox switched to rapid release schedule in 2011. It was long time ago when the web and Mozilla was very different. And it was clear at that time that the older release schedule does not work. A browser became a set of complex technologies for very different domains and it was not possible to develop them in sync making the major.minor distinguish meaningless.

As a mozillian at that time I only wished that Mozilla has not blindly copied exact setup from Google. 6-week cycle and the exact arrangement of channels were nothing magic and reflected internal Google processes.

GNOME's new versioning scheme

Posted Sep 18, 2020 1:19 UTC (Fri) by IanKelling (subscriber, #89418) [Link] (4 responses)

I like the change.

GNOME's new versioning scheme

Posted Sep 18, 2020 1:45 UTC (Fri) by koh (subscriber, #101482) [Link] (3 responses)

I do not.

Any reasons?

GNOME's new versioning scheme

Posted Sep 20, 2020 18:50 UTC (Sun) by ballombe (subscriber, #9523) [Link] (2 responses)

People are bad at remembering big numbers. After some point they look all the same.
People more easily remember 4.2 than 42, and at least they will remember it is 4.something
while they will mix 52,62 and 72.

GNOME's new versioning scheme

Posted Sep 21, 2020 10:07 UTC (Mon) by NAR (subscriber, #1313) [Link]

People more easily remember 4.2 than 42

I'm not sure. One trick to remember numbers is to "relate" the number to something else - I mean 42 is the number of the bus line used to go around here. (19)62 is the date when Brazil won its second soccer World Cup. 72 is the number of a road near lake Balaton. But what is 4.2?

GNOME's new versioning scheme

Posted Sep 21, 2020 10:57 UTC (Mon) by mbunkus (subscriber, #87248) [Link]

Doesn't the same reasoning apply to the minor component? Maybe even more so?

Going from 42 to 85 vs 3.42 to 3.85 doesn't seem to make much difference to me. In fact, I'd argue that the first example is easier to remember due to the tenths changing. Of course that advantage goes away once you're above 100, e.g. from 142 to 185 will likely be as easy (or hard) to remember as 3.42 to 3.85.

Now going from 82 to 85 vs 3.82 to 3.85: here I don't see it making any difference at all.

Another point: staying with a major.minor scheme and keeping the same major for an extensive period of time could also lead to false sense of the project not changing much, thinking "oh it's still v3" about going from 3.42 to 3.85 while the project might actually have changed drastically.

I think my point is that there are advantages and disadvantages to every scheme. As long as numbers go up, I don't care that much. When I have projects for which I need to care about the semantics of their versioning, I need to learn about their scheme and act accordingly. With every project, 'cause there simply isn't any one standard (yeah yeah, semantic versioning, but I still need to determine if a project follows that scheme in the first place).

GNOME's new versioning scheme

Posted Sep 18, 2020 3:57 UTC (Fri) by joshl (guest, #91369) [Link]

The 3.38 release announcement highlights some really neat, technical features such as support for mixed refresh rate set-ups complete with a bit of insight into the internals of mutter and how the feature was developed:

https://blogs.gnome.org/shell-dev/2020/07/02/splitting-up...

Interesting, right? No, actually; I don't understand it. However, what I do understand is numbering things and I have no shame in making that very clear to all.

GNOME's new versioning scheme

Posted Sep 18, 2020 15:31 UTC (Fri) by tlamp (subscriber, #108540) [Link]

They probably want to pull off the same thing openSUSE (or however the casing is nowadays) did. Either for:
  • getting press. There's no such thing as bad press, aka the Silvio Berlusconi principle
  • also having to many meetings in smoke filled rooms, hopefully while still adhering to social distancing rules
  • early, or late, April joke
So placing bets on them going back to 5.0 or so in a few months.

Anyway, really wondering what goes off in peoples head when making decisions like this, sleeping over them and still thinking that they should go forward with it. But yeah, gotta keep that 2020 ride going...


Copyright © 2020, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds