4 ms·

I think I speak for everybody here when I say that 1.8 + 0.2 = 1.10.

by kennu 15y ago

cheald 15y ago
Yes indeedy. The "2.0" versioning is seriously annoying me.
benburton 15y ago
I'm very confused about the math you did there.
- milestinsley 15y ago
  The 0.2 implies two "point releases". Traditionally these increment the value after the decimal point in a version number. so: 8 + 2 = 10, therefore 1.10. It's best to view the version number as a string rather than a decimal number. This is a somewhat old-school way of versioning and common in open source software. Personally, I prefer something more intuitive and don't see anything wrong with MongoDB being at version 2.0!
  - TylerE 15y ago
    The point of a major bump is to say to the ops team/sysadmin "HEY! We actually changed some stuff. You probably want to check with your programmers to see if any of these changes will effect our client code".
  - icebraining 15y ago
    I think if they want to keep it purely arithmetic they should drop the period. It's MongoDB 20.
  - icebraining 15y ago
    I think if they want to keep it purely arithmetic they should drop the period and just use integers.
TylerE 15y ago
3rded. A major version bump should indicate major changes e.g. time to go through any code that talks to the server. If they just want to have a number that grows, they should do something like vRELEASE.MINOR.
Pewpewarrows 15y ago
Sorry, but no. You seem to still be trapped in the ancient mindset that an increment in the most significant version number must mean huge changes. Instead, more often than not, it's merely a milestone signifying that all of your intended features that you outlined in the previous major version's days have been completed. So when 1.0 hits (or close to it), you define a bunch of "must-haves" for 2.0, along with all the bugs and smaller improvements that come up along the way. Now you can wait 18 months, only issuing security patches for 1.0.x, and then deliver all of those features all at once with a 2.0 party. Or as each feature is complete, you release a new minor version (1.1 for foo, 1.2 for bar, etc). Once you're able to scratch off the last of your list for 2.0, you bump the version number up and call it a day, from wherever you are along the 1.x line (be it 1.1 or 1.42). With sufficient planning, you can manage to make it so that you never have to go into 1.xx territory (with double digit minor version numbers). I'm sure I'm not alone in finding 1.10 to be aesthetically ugly. If you have to, then by all means. Avoid it if you can, but at the end of the day milestones should always be your metric for release numbers. Now in Mongo's case they might just be incrementing the major version number for the hell of it. But I'm assuming they actually planned this out.
- stingraycharles 15y ago
  You seem to still be trapped in the ancient mindset that an increment in the most significant version number must mean huge changes. Isn't it more about personal preference rather than having an "ancient mindset"?
- mnutt 15y ago
  He's referring to this: "Please note version 2.0 is a significant new release, but is 2.0 solely because 1.8 + 0.2 = 2.0; for example the upgrade from 1.6 to 1.8 was similar in scope."
aaronblohowiak 15y ago
You dont speak for everybody here, but it would seem to agree with Semver: http://semver.org/ http://semver.org/
deleted 15y ago
[deleted]
protomyth 15y ago
Considering that some projects such as OpenBSD have a set release schedule that add a 0.1 to the version, I don't think you speak for everyone. OpenBSD 5.0 is in its final stages before release and the 5.0 simply means it came after 4.9.

I think I speak for everybody here when I say that 1.8 + 0.2 = 1.10.

by kennu 15y ago

I think I speak for everybody here when I say that 1.8 + 0.2 = 1.10.

cheald 15y ago

Yes indeedy. The "2.0" versioning is seriously annoying me.

benburton 15y ago

I'm very confused about the math you did there.

milestinsley 15y ago
The 0.2 implies two "point releases". Traditionally these increment the value after the decimal point in a version number. so: 8 + 2 = 10, therefore 1.10. It's best to view the version number as a string rather than a decimal number. This is a somewhat old-school way of versioning and common in open source software. Personally, I prefer something more intuitive and don't see anything wrong with MongoDB being at version 2.0!
- TylerE 15y ago
  The point of a major bump is to say to the ops team/sysadmin "HEY! We actually changed some stuff. You probably want to check with your programmers to see if any of these changes will effect our client code".
- icebraining 15y ago
  I think if they want to keep it purely arithmetic they should drop the period. It's MongoDB 20.
- icebraining 15y ago
  I think if they want to keep it purely arithmetic they should drop the period and just use integers.

TylerE 15y ago

3rded. A major version bump should indicate major changes e.g. time to go through any code that talks to the server. If they just want to have a number that grows, they should do something like vRELEASE.MINOR.

Pewpewarrows 15y ago

Sorry, but no. You seem to still be trapped in the ancient mindset that an increment in the most significant version number must mean huge changes. Instead, more often than not, it's merely a milestone signifying that all of your intended features that you outlined in the previous major version's days have been completed. So when 1.0 hits (or close to it), you define a bunch of "must-haves" for 2.0, along with all the bugs and smaller improvements that come up along the way. Now you can wait 18 months, only issuing security patches for 1.0.x, and then deliver all of those features all at once with a 2.0 party. Or as each feature is complete, you release a new minor version (1.1 for foo, 1.2 for bar, etc). Once you're able to scratch off the last of your list for 2.0, you bump the version number up and call it a day, from wherever you are along the 1.x line (be it 1.1 or 1.42). With sufficient planning, you can manage to make it so that you never have to go into 1.xx territory (with double digit minor version numbers). I'm sure I'm not alone in finding 1.10 to be aesthetically ugly. If you have to, then by all means. Avoid it if you can, but at the end of the day milestones should always be your metric for release numbers. Now in Mongo's case they might just be incrementing the major version number for the hell of it. But I'm assuming they actually planned this out.

stingraycharles 15y ago
You seem to still be trapped in the ancient mindset that an increment in the most significant version number must mean huge changes. Isn't it more about personal preference rather than having an "ancient mindset"?
mnutt 15y ago
He's referring to this: "Please note version 2.0 is a significant new release, but is 2.0 solely because 1.8 + 0.2 = 2.0; for example the upgrade from 1.6 to 1.8 was similar in scope."

aaronblohowiak 15y ago

You dont speak for everybody here, but it would seem to agree with Semver: http://semver.org/ http://semver.org/

deleted 15y ago

[deleted]

protomyth 15y ago

Considering that some projects such as OpenBSD have a set release schedule that add a 0.1 to the version, I don't think you speak for everyone. OpenBSD 5.0 is in its final stages before release and the 5.0 simply means it came after 4.9.