Xfce 4010 – (release-schedule and versioning)

Hi all,

There has been a lengthy discussion about the xfce version-number.
Is it OK to call the next version of xfce 4.10?

Some package maintainers have a problem with 4.10 being a later version then 4.8, since they see 4.10 as 4.1 with an extra decimal for precision.

Since it could cause upgrade-problems for several distributions, we should find a way to solve that problem.

Why not go for 5.0?

If the ‘.’ is a decimal-separator, a 0.2 upgrade from 4.8 would end up at Xfce 5.0. But we already discussed that . We are not going for 5.0, it would only create confusion, and people start thinking we pulled a ‘gnome-3’ on them. So that one was out pretty quick.

But, the confusion remains. Olivier Fourdan argued that we could think of it as a hexadecimal value, so 0x4.8 would be followed by 0x4.A. Though this sounds funny, and it solves our problem for a few versions (0x4.C, 0x4.E) but we’d end up with 0x5.0 eventually… resulting in the same problem.

And nobody uses the hexadecimal system for version-numbers, that is silly.

So? Now what?

It took a while before we realized, that the ‘.’ could be seen as a separator for thousands (it’s used like this in most of Europe). So you’d have Xfce 4,008 and Xfce 4,010. This not only solves our problem for the next version. At the rate of one release every 2 years we stay away from the whole 5.0 discussion for another 990 years. (Unless another reason appears to introduce a 41xx series of 50xx series of Xfce somewhere this century).

So, here’s the conclusion:
The next version of Xfce will be Xfce 4010 (four-thousand-and-ten)!

But that’s ridiculous!?

Well, it used to be. But these days anything is possible with version-numbers really, except for going backwards.

Which is precisely what we are avoiding here.

Just look at Mozilla Firefox (moving from 4 to 9 at the same pace as they went from 0.7 to 1.0) or Google chrome (what version-number are they using anyway?), or the linux-kernel, going from 2.6.0 to 2.6.39 with entire subsystems being rewritten from scratch, and then moving from 2.6.39 to 3.0 without any radical change whatsoever.

Really, moving from 4.8 to 4010 is not really that big a deal, if it serves the right purpose.

That’s nice and all, but when will we get it?

Ah, more good good news :)

We have a new schedule. (it is not published to the wiki yet though)

Essentially, the development-phase is pro-longed until the weekend after FOSDEM, giving us time to do some hacking there and get it in master the week after.

Dates Phase/Deadline Everyone’s Tasks Release Team Tasks Maintainer Tasks
2011-Feb-13 – 2012-Feb-12 Development Phase Support Xfce Supervise development, remind people of deadlines Hacking
2012-Feb-12 – 2012-April-01 Release Phase Wait patiently Perform releases, remind people of deadlines Perform releases of own components if desired
Xfce 4010pre1 (Feature Freeze) Prepare release announcements, release Xfce 4010pre1 Make sure the latest development release is in good shape and uploaded
Xfce 4010pre2 (String Freeze) Prepare release announcements, release Xfce 4010pre2 Make sure that strings in the latest development release or in master are good
Xfce 4010pre3 (Code Freeze) Prepare release announcements, release Xfce 4010pre3, create ELS branches Make sure the latest development release is in good shape, or that code is solid/finished in master
Xfce 4010 (Final Release) Celebrate Prepare release announcements, release Xfce 4010, branch for stable release, merge ELS branches into master Make sure to upload a new release of own components before this deadline

We hope you are as happy as we are with the new release schedule.

Update: There was some confusion about the date notation, updated it to get rid of the month-numbers.

Update-2 [18-01-2012 13:37 CET]: For more background information about this decision, check this link

8 thoughts on “Xfce 4010 – (release-schedule and versioning)

  1. 8, 9, 10, 11? skip 10, use 11(you skipped 9, so you can skip another number), 4.11 is bigger then 4.8. there is problem?

  2. @gymka: The problem is that apparently some package managers expect the version to be a decimal number (x.yy), not (major.minor) as two distinct fields. It is traditional for odd minor version numbers to represent development versions and even numbers to represent stable releases. That is why 9 is skipped.

    Thus the problem is that some package managers see 4.10 as equal to 4.1. Since 4.1 < 4.8, they will not upgrade.

    @Stephan: this issue must have been addressed by other applications in the past. You mentioned the Linux kernel, which uses three fields, which is clearly not decimal or Gnome, which made it up to 2.32 before moving to 3.0. What did they do for these applications? I know sometimes Debian does some odd things like kdeutils-4:3.5.9-2.

    My favorite oddball version jump was Slackware, when Patrick followed version 4 with version 7, to show how it was clearly superior to RedHat version 6…

    Why do we need to go to 4010? Are you planning to release more than 89 more versions of Xfce 4? You could simply drop the decimal and get 410. Or you could leave it up to the package maintainers, who might simply do that for their distributions. Thus on Debian, we'd be running Xfce 4.10 and on OddBall, they'd be running Xfce 410 according to the package specs but the About window would still read "4.10." After all, it's really on the spec files for particular distributions that need to change and I'm sure they've dealt with this issue before, since many applications use version numbers with minor numbers of 10 and up.

  3. And, before someone says something, 4.12 (or 4.72) would still be less than 4.8, so the problem remains even if you skip many versions.

    I believe Stephan’s reasoning is, “if we have to skip a lot anyway, why not just drop the decimal and avoid it happening again further down the road?” It seems reasonable to me. I just wonder where that zero between the 4 and 10 came from (added for extra minor versions?).

  4. @troberson: I totally agree with your view. Calling the next version of XFCE 4010 IMHO still is ridiculous, as lots of other packages dealt with such version numbers as well.

  5. The whole problem is far-fetched. I’d like to personally smash package maintainer who can not deal with such version numbers.

  6. i love xfce, no matter which number it is.
    im ubuntu user but im using xfce. its really great.
    its sooooooooooo fast :)

Comments are closed.