[adim86]

It is amazing to see software that is about 10 years old just hitting 1.0. Never really quite understood that. Is the developer just not confident in it that it is in beta for a while? or is it just a style of versioning? Anyways glad to see development on handbreak.Great software!

[stuaxo]

Lots of open source takes 10 years to hit 1.0.

Though 1.0 usually has a different meaning in both world's.

1.0 usually includes a set of features the project had in mind at the beginning in open source. Whereas in closed source it usually means the first version that works to a minimal extent.

Closed source 1.0 equals open source 0 point something.

[spacemanmatt]

I generally take version numbers near 1 to be market communication about stability/fitness. Above that, I take version numbers as a loose grouping of significant change sets.

[bluejekyll]

Versioning is generally arbitrary. I actually don't know why people pay so much attention to it.

1.0 for some people, is 0.1 for others.

1.0 might mean it's stable, or it could meant that it's feature complete. As you say it could also be used to convey the confidence the developers have in the software.

The thing I find most important myself is conveying compatibility, i.e. semver. To me that tells me it will be easy to upgrade a library, or it could be hard.

[alephnil]

It is not completely arbitrary though. Usually 1.0 for proprietary software means "the first version shipped to customers", while for open source, the very first commit is 0.0, and then it goes from there. Since it is public from the start there is no 1.0 moment. Sometimes, especially for programming languages, the 1.0 version is used to signal that from no on there will be no arbitrary change to syntax or semantics after that, so that it can be relied on.

Traditionally, version numbering has been used to signal the significance of the release. for version x.y.z, you could expect that

  * x is incremented: Major new features, possibly incompatibilities
  * y incremented but not x: Minor new features and bug fixes.
  * z changed only: Bug fixes only.

This was generally observed in both proprietary and open source software alike, and is still used in many projects. Recently many projects has abandoned this pattern, including Chrome and Firefox, the Linux kernel and others.

Of cause there has always been a pressure from the marketing departments to have a new major release, while the engineers has been holding back, so you have always seen major releases that isn't that major, and sometimes incompatible changes sneaked into minor releases. The latter has generally been considered bad form.

[dvdhnt]

I can generally agree with this save for two cases. One, I've found that major bumps in a programming language are significant, especially in the case of something like python 2 vs 3. Second, a lot of major javascript players have been using major bumps mainly in the case of breaking APIs, removing functionality, etc (ex: Lodash, ExpressJS, and - soon - React).

Contrarily, I've noticed in Rails that A LOT of major refactoring and functionality has been added via minor bumps that, while still backwards compatible for Rails itself, often breaks custom implementations, usually related to javascript modules and configs.

Overall, though, I agree with you.

[Tempest1981]

Then there was Java, where 1.5 meant 5.0. And Win 7, which is 6.1 internally.

(When engineering and marketing aren't on the same page?)

[marcosdumay]

You develop and test as fast as you have time to.

HandBrake probably does not bring money to its developers, so the pace is inherently limited.

[ZenoArrow]

It's not necessarily about the pace. Some 0.x software is more feature complete than other 1.x software. It's not possible to compare versions between different pieces of software to infer anything meaningful about how much work went into them.

To give an example, it took VLC a long time to reach version 1, yet even in its 0.x releases it was amongst the best video players available (in terms of features, performance and stability), better than many other closed-source competitors with higher version numbers.

In other words, aside from libraries and programming languages (where major version numbers do have extra significance), version numbers are only loosely coupled to software quality.