x264 v 1.0.0 ??

[audyovydeo]

Hello

I've just noticed the latest changelog.

x264 now does BluRay, zero latency, error resilience, and a lot more, at a unique quality/speed ratio.

Does it not deserve a 1.0.0 as opposed to a 0.100.1659 ?

(incidentally, for r1658, lookaheadless == lookbehind)


cheers,
(tongue-in-cheek) audyovydeo

[Atak_Snajpera]

As the matter of fact only last numbers are important for me ;)

[Warpman]

I'd like to quote Loren on that

<pengvado> making an alpha product into final is easy
<pengvado> the hard part is adding features so that it stays alpha

:p

[Dark Shikari]

0.100 looks close enough to 1.00 for me!

[burfadel]

Due to the nature of hte update cycle the current version numbering is ideal. Problem with releasing it as v1.00 is that people will thing that v1.00 is better over any later mintor revision, unless you call those v1.01, v1.10 etc. That would only create needless confusion.

[Soichiro]

The devs could go with some complicated naming scheme like naming the current version 1.0.00, then a minor revision would lead to 1.0.01, then a big new feature or something would be 1.1.00, then if they just randomly decide, they can make x264 version 2.0... or they could stick with the current, simple revision-based scheme. x264 will most likely never stop being revised until H.264 itself becomes obsolete, so making a version 1.0 at an arbitrary point in time doesn't really make sense.

[Midzuki]

IF POSSIBLE, I'd like to see a "definitive" and "perfect" version of x264 :devil: but I already know that...

not only AVC is an extremely-complicated subject,
but also, and worse, the H264 (and the Blu-Ray) specs were NOT written during a "minimally-sane" state-of-mind.

So I'd rather keep assuming the x264 team will always be much-more qualified than wannabe pseudo-nerds like myself. :o

[kypec]

I hope they won't change revision numbering anytime soon.
It's simple yet perfect as it is now:
Developer asks "what revision of x264 are you using?"
User replies "rXXXX"
Developer suggests "please use newer/most recent revision i.e. the one having HIGHEST rYYYY number"
and the last reply applies forever :)

[Maccara]

Problem with releasing it as v1.00 is that people will thing that v1.00 is better over any later mintor revision, unless you call those v1.01, v1.10 etc.

Oo! Can we get v1.1 and later v1.10 so we can have the endless confusion of v1.1 < v1.10 when people don't realize version numbers != decimal numbers (i.e. they mean whatever the devs choose them to mean). :p (it's even funnier when people start to argue with the devs about that :D)

[burfadel]

Yeah exactly! Whats the difference between using the current system and calling it rev 1659, or calling it 16.59 or 1.659? Absolutely none! If x264 was only updated every few months like normal software, then a more common versioning system may be possible (but not necessary).

[LoRd_MuldeR]

If the x264 developers did maintain various branches and/or had planned milestones, it would make sense to have different version numbers. Like 1.x is the "previous" release series, 2.x is the current "stable" release series and 3.x is the upcoming "development" series. However that obviously isn't how x264 is developed. Instead they constantly improve and fix the "HEAD" branch like hell without looking back. And so far this has turned out to work perfectly fine for the project. So counting "only" revision numbers and API changes seems like the most reasonable approach here...

[bob0r]

0.0000001659 pre-alpha.

[Bi11]

The only way I can see x264 v1.0.0 being realistically practical without "revision confusion" and the viral spread of old broken versions, is for x264 to somehow know it's old.

Either x264 itself can check for updates, or the "official x264 GUI" hosted on the "official x264 website" would check for updates.
If there is ever an "official x264 GUI" then x264 v1.0.0 would be fitting. :)