What's in a name?

List overview All Threads
Download

newer

older

Vector skin not working on...

Re: [Wikitech-l] Selenium testing...

Chad

26 May 2010 26 May '10

noon

Good afternoon, This morning I bumped the revision number to 2.0[0]. Some people on IRC didn't like this, so I reverted it and I'm bringing it here. I don't think anyone really wants to keep doing 1.x releases (people seriously get confused that 1.10 comes after 1.6). The following suggestions have been put forward: - Drop the 1 from 1.17.x and make the releases start counting from 17.x, 18.x, etc. - Bump 1.x to 2.0 and move forward from there. - Drop numbers entirely, and pick silly names Thoughts? -Chad [0] http://mediawiki.org/wiki/Special:Code/MediaWiki/66923

Show replies by date

Aryeh Gregor

26 May 26 May

12:12 p.m.

On Wed, May 26, 2010 at 3:00 PM, Chad <innocentkiller(a)gmail.com> wrote:

...

This morning I bumped the revision number to 2.0[0]. Some people on IRC didn't like this, so I reverted it and I'm bringing it here. I don't think anyone really wants to keep doing 1.x releases (people seriously get confused that 1.10 comes after 1.6).

I'm fine with doing 1.x releases forever. It's worked for a lot of other projects, and it's the least confusing option compared to changing systems. Confusion about 1.9 being before 1.10 will abate -- 1.9 is already pretty old, and will only get older. We're not going to hit 1.100 anytime soon.

...

The following suggestions have been put forward: - Drop the 1 from 1.17.x and make the releases start counting from 17.x, 18.x, etc.

I don't mind this, although it would be needlessly disruptive.

...

- Bump 1.x to 2.0 and move forward from there.

I object to this. It makes it seem like the jump from 1.16 -> 2.0 is more important than the one from 1.15 -> 1.16 or 2.0 -> 2.1, and that's just not the case.

...

- Drop numbers entirely, and pick silly names

We shouldn't drop numbers. That's just too confusing given how often we release. It's only practical if you release like once every three years or less (like Windows), and even then only if you're high-profile enough that you can expect people to remember the order.

Neil Kandalgaonkar

2:31 p.m.

On 05/26/2010 12:12 PM, Aryeh Gregor wrote:

...

On Wed, May 26, 2010 at 3:00 PM, Chad <innocentkiller(a)gmail.com> wrote:

This morning I bumped the revision number to 2.0[0]. Some people on IRC didn't like this, so I reverted

I'm fine with doing 1.x releases forever. It's worked for a lot of other projects, and it's the least confusing option compared to changing systems.

Major version number changes often are taken to mean that: - this release is incompatible with the last (new db schema, new APIs?) - something's changed that should make everyone should reconsider any product decisions for or against. Even if you don't mean anything by the number change, a lot of people are going to assume you mean this. So you should think carefully before doing this. A major version change requires at the very least lots of documentation, marketing, blog posts, etc. -- Neil Kandalgaonkar ( ) <neilk(a)wikimedia.org>

church.of.emacs.ml

12:46 p.m.

...

Hi Chad, thanks for that initiative. I agree our current system is confusing, although I think criticism would have been better placed 2.5 years ago, when we released 1.10 ;)

...

- Drop the 1 from 1.17.x and make the releases start counting from 17.x, 18.x, etc.

Would work, although its confusing to change existing releases. And it isn't practical in case we want a new major realease someday (Phase IV anyone? ;))

...

- Bump 1.x to 2.0 and move forward from there.

Should be done for the next major release (if we ever have one of those)

...

- Drop numbers entirely, and pick silly names

Doesn't make releases less confusing. I agree that our current schema sucks, but at least until we have some kind of major release that would justify moving to 2.0, I don't see a good alternative. Regards, CoE

Schneelocke

1 p.m.

On Wed, May 26, 2010 at 21:00, Chad <innocentkiller(a)gmail.com> wrote:

...

To offer a bystander's view - I'm not a big fan of big version number jumps (e.g. 1.x -> 2.x) without there really being major changes to justify them, but here's an idea: continue with 1.17, 1.18 and 1.19, then drop the one and make 1.20 version 2.0 instead. After that, continue the way that e.g. OpenBSD does: treat the separator as a decimal point so that 2.9 will eventually be followed by 3.0, and so on. That way, there won't be any confusion about e.g. 1.10 being newer than 1.6 anymore, you don't have to choose between either keeping a meaningless version number component ("1.") around forever or hoping for sufficiently large changes to justify a jump to a higher version number (something that may not fit that well with a continuous, integrated development model like Mediawiki's, anyway), and there shouldn't be any potential for future confusion anymore. Just an idea. :) -- schnee

Lane, Ryan

1:21 p.m.

...

The Linux kernel has been at 2.6.x for years, and it is likely it'll never have a 2.7 release. Seems to work for them.

...

- Drop the 1 from 1.17.x and make the releases start counting from 17.x, 18.x, etc.

As long as we don't go the Solaris route, and have releases called 1.17.x, 17.x, 1.18.x, 18.x, etc..

...

- Bump 1.x to 2.0 and move forward from there.

Mozilla has been doing this with firefox lately, and although it gets some WTF responses, it doesn't seem to cause confusion.

...

- Drop numbers entirely, and pick silly names

I *hate* named releases. Codenames aren't bad for future releases, but names for current and past releases become confusing fast. This is especially true if there are name and number releases like Ubuntu. I often find myself doing searches in google like this: "ubuntu <version number> name". Developers and document writers often refer to names and version numbers interchangeably as well, which dissects documentation. Names are especially confusing when looking at documentation. "Ok, this documentation is for Edgy... Which version is Edgy? Which name am I supposed to be looking for?" Please no named releases. Otherwise, let's try to not change our convention unless we really need to. Changes in naming conventions make searching for documentation harder. Try to find documentation for essentially any Sun product, and you'll know what I mean. Respectfully, Ryan Lane

Conrad Irwin

1:40 p.m.

On 26 May 2010 21:21, Lane, Ryan <Ryan.Lane(a)ocean.navo.navy.mil> wrote:

...

> This morning I bumped the revision number to 2.0[0]. Some > people on IRC didn't like this, so I reverted it and I'm bringing > it here. I don't think anyone really wants to keep doing 1.x > releases (people seriously get confused that 1.10 comes after > 1.6). The following suggestions have been put forward: >

Wouldn't removing 1.6 from the main page solve the problem for most newcomers? Only those who go down to the PHP 4 section of the downloads need ever know it exists and thus get the impression that it is an older version. Once they're no-longer newcomers, we can hope that they'll have a feel for how version numbers work. Conrad

Platonides

2:17 p.m.

Conrad Irwin wrote:

...

+1 for removing 1.5 from [[MediaWiki]] and [[Download]]. (also see today post "which is the latest version of MediaWiki available?" at mediawiki-l)

Chad

2:47 p.m.

On Wed, May 26, 2010 at 4:40 PM, Conrad Irwin <conrad.irwin(a)gmail.com> wrote:

...

On 26 May 2010 21:21, Lane, Ryan <Ryan.Lane(a)ocean.navo.navy.mil> wrote:

To be honest I think we should remove it from everything. I know it requires practically zero work to maintain, but the longer it sits around the more people will be encouraged to stick with PHP4 and not move on. PHP in general has faced this for years. While the world has moved on to 5 now, there are some lingering hosts who refuse to upgrade, and keeping PHP4 products around keeps them from seeing the need to upgrade. -Chad

Aryeh Gregor

2:55 p.m.

On Wed, May 26, 2010 at 5:47 PM, Chad <innocentkiller(a)gmail.com> wrote:

...

I don't think our goal should be to get hosts to upgrade to PHP5. I doubt we'd be very effective at that at all. If there aren't a substantial number of users still on PHP4, though, we may as well remove the mention of 1.6 as a distraction, like for the benefit of people who don't know what PHP version they have (but probably have 5). It hasn't been mentioned in the #mediawiki /topic for some time.

Happy-melon

3:11 p.m.

"Chad" <innocentkiller(a)gmail.com> wrote in message news:AANLkTimePLHM2O6_2-Dkr5EPkpt-PG2Hr5qTcmSrFzdk@mail.gmail.com...

...

I really fail to see any advantage to throwing away the major.minor version schema. If people are misinterpreting 1.15 as being less than 1.6, and are determined to continue to believe that despite all our best efforts to the contrary, then joggling the numbers around a little is really not going to improve their experience of MediaWiki; getting the wrong version is really the least of their worries. I do agree that dropping 1.6, or at least restoring the "this is the ancient version, don't use it unless you really have to" messages that I definitely remember but which seem to have vanished, might be beneficial overall; but I really don't see any point in changing schemas for the sake of it. I'm very much up for a MW 2.0 where we take the opportunity to clear out some of the many nasty idiosyncracies that we've accumulated over the past seven years; but I see no problem with continuing 1.xx indefinitely until that time, and no point in 'invoking' a major version change for a release which is not really any different to other recent releases. If we're going to bite the bullet and *make* 1.17 worthy of a new major version, then fair enough. But I haven't seen that happen yet. --HM

Alex

3:36 p.m.

On 5/26/2010 3:00 PM, Chad wrote:

...

This seems kinda odd. Then we have the issue of people wondering why we go 1.16.0 -> 17.0. (Where did the other number go? What happened to versions 2-16?)

...

- Bump 1.x to 2.0 and move forward from there.

I think we should go to 2.0 eventually, but it should wait until we add some major new feature(s) and/or make some big breaking change that will require changes to lots of extensions or for people to do something more than just run update.php to upgrade.

...

- Drop numbers entirely, and pick silly names

Ew, no. Besides the confusion issue others have noted, it also creates issues with things like bot frameworks or anything else automated that may need to check the version of a wiki. Rather than simply checking against less than/equal/greater than a number, they have to maintain a mapping of name->number.

...

Thoughts?

I would support dropping the 1.6 branch from the download listings and dropping support for it (if we haven't already; the last release was more than a year ago). PHP apparently stopped releasing security updates for PHP4 nearly 2 years ago.[1] Are there any statistics for the download server so that we could see how many people are actually downloading 1.6? [1] http://www.php.net/archive/2007.php#2007-07-13-1 -- Alex (wikipedia:en:User:Mr.Z-man)

Tisane

9:57 p.m.

In the extensions I've written, I've usually used the x.x.x naming convention, similar to the MediaWiki core's. But in light of the comments made in this conversation, I considered using integers. E.g. advance from version 9 to version 10 rather than from 1.1.9 to 1.1.10, and thus avoid confusion about which version is after another. However, that eliminates the ability to use the version number to denote major releases. I haven't seen very many decimal systems in which, say, version 3.31 was a minor improvement over 3.3, since the DOS era. The new standard seems to be the type of system MediaWiki uses. And for good reason, because it defeats the point if, just because there are only 10 possible digits in the base 10 number system, you have to go from 1.1.9 to 1.2.0 even though it's not a major release. I see pitfalls no matter what we do, but the current version system is probably the best option available. We may never reach version 2.0.0, but we leave the door open for it. Speaking of extension versioning conventions, I wonder if my using the x.x.x convention will generate confusion as to whether the extension's version or the compatible MediaWiki version is being referred to? - Tisane

Tim Starling

10:38 p.m.

On 27/05/10 05:00, Chad wrote:

...

I think we should continue to do 1.x releases, until such time as we make a large enough change to justify incrementing the major version number. I think we could have gone from 1.9 to 2.0, but that opportunity passed 3 years ago. As Aryeh says, the problem of people getting confused about 1.6 vs 1.10 will diminish with time. I've stopped backporting security fixes to 1.6. As far as I'm concerned, it's not supported anymore. -- Tim Starling

5076

days inactive

5077

days old

wikitech-l@lists.wikimedia.org

Manage subscription

13 comments

12 participants

tags (0)

participants (12)

Alex
Aryeh Gregor
Chad
church.of.emacs.ml
Conrad Irwin
Happy-melon
Lane, Ryan
Neil Kandalgaonkar
Platonides
Schneelocke
Tim Starling
Tisane