[mbreese]

Version numbers are just a thing

Yes, and they should mean something. Not having a fixed API/ABI for an entire major version goes against what everyone else thinks that version numbers mean. You can talk yourself into thinking that the numbers don't matter - that only the semantic versioning (whatever that is) matters. But that doesn't mean that everyone else will agree, let alone understand what the hell you're talking about.

[audidude]

The situation with 4.0 not being 4.x is most certainly the most contentious part of the discussion so far. It is also subject to change (it's only been a few hours so far of us discussing this).

That said, if we can't guarantee the minor versions as we drain the swamp to rebuild this toolkit into something modern, we either need to not release anything (which makes it very hard to build if you can't get users to test things) or we need to come up with alternate versioning schemes.

[mbreese]

I was always a fan of the older linux model: x.1 = unstable, x.2 = stable, x.3 = unstable, x.4 = stable.

Really, the reason why this strikes a chord is that it is confusing as hell. What is the rationale behind not allowing a 4.2 project to be built once 4.4 is installed on the system? That is the truly confusing part. Are you expecting that many backwards incompatible changes between 4.2 and 4.4? Why do the headers and packages need to share the same namespace?

I'm sure a lot of thought went into this, but something just doesn't seem right to me...

[audidude]

> I was always a fan of the older linux model: x.1 = unstable, x.2 = stable, x.3 = unstable, x.4 = stable.

This certainly came up in our discussions... I think many people were left with a bad taste in their mouths due to trying to decode Linux version numbers. In my opinion, anything that has an actual decode algorithm would be better than the current situation of ... i dunno? :)

> Really, the reason why this strikes a chord is that it is confusing as hell. What is the rationale behind not allowing a 4.2 project to be built once 4.4 is installed on the system? That is the truly confusing part. Are you expecting that many backwards incompatible changes between 4.2 and 4.4? Why do the headers and packages need to share the same namespace?

I think this was miscommunication to be honest.

The installation headers for 4.0, 4.2, 4.4, etc will not be parallel installable based on the current idea. So when your distribution upgrades to 4.4, anything you compile against the -devel headers will be for 4.4. However, if they keep the previous soname version for 4.2, I don't see any reason that program couldn't keep working.

Of course, we could try to discover the ABI incompatabilities with libabigail, but history has shown us (over the last couple years) that there is a lot to ABI breakage that has nothing to do with symbols. Theming, expected behavior...

> I'm sure a lot of thought went into this, but something just doesn't seem right to me...

We certainly appreciate feedback. We are trying to be reponsive on irc.gimp.net #gtk+ during the hackfest, and your concerns will be relayed to the group. We are a fairly small group of about a dozen people, but gtk+ is important to us and we care about improving things.