Register

If this is your first visit, please click the Sign Up now button to begin the process of creating your account so you can begin posting on our forums! The Sign Up process will only take up about a minute of two of your time.

Results 1 to 5 of 5
  1. #1
    Senior Member duck444's Avatar
    Join Date
    Feb 2003
    Location
    east coast
    Posts
    404
    Member #
    751
    Liked
    2 times
    How or why do they number software programs and script releases they way they do?

    For example, I've seen a script release numbered version 1.6.3. Are there universal rules that govern these numbers?

    If so what are they?

    Thanks..

  2.  

  3. #2
    Senior Member filburt1's Avatar
    Join Date
    Jul 2002
    Location
    Maryland, US
    Posts
    11,774
    Member #
    3
    Liked
    21 times
    It's not formalized, but: x.y.z, where:

    x: Major version; significant new features, potential incompatibility with previous versions, buy-again-worthy according to the developer
    y: Minor version: notable new features, worth upgrading to but probably not paying for
    z: Revision: bug fixes, no notable new features

    Sometimes there's a long number after the revision (x.y.z.b), where b is the build number, which is an autogenerated number based on the number of times the entire project was compiled to date, committed to a versioning system, etc. Microsoft uses build numbers pretty often, and some retarded (did I just say that?) projects like http://www.cakephp.org/ also do it.

    Example with Mac OS: 10.5.1.
    10: Major version, massively incompatible with previous versions, tons of new features; essentially an entirely new product
    5: Minor version: new features, usually upgrade-worthy from previous 10.x versions
    1: Bug fixes to the 10.5 branch

    (although with Mac OS, they've been at 10 for years; there won't be a Mac OS 11 for a long time)
    filburt1, Web Design Forums.net founder
    Site of the Month contest: submit your site or vote for the winner!

  4. #3
    Senior Member duck444's Avatar
    Join Date
    Feb 2003
    Location
    east coast
    Posts
    404
    Member #
    751
    Liked
    2 times
    Thank so much for that answer, filbert. That was awesome!

  5. #4
    Senior Member planetgman's Avatar
    Join Date
    Jun 2005
    Posts
    569
    Member #
    10406
    Yep, what he said......

    Very well explained though Filburt!
    GMan

  6. #5
    Senior Member
    Join Date
    Jun 2005
    Location
    Atlanta, GA
    Posts
    4,146
    Member #
    10263
    Liked
    1 times
    Basically, there's no real telling, except that changing the first version number will typically mark, as filburt pointed out, major changes, and typically will throw compatibility out the window. Some release cycles:

    Linux uses the first number to indicate basically a total rearchitecting of the kernel. They've been through one of those, which is why we are at the 2.x.x kernels. The second number is the `minor' version, which is typically used to indicate large changes in the codebase. Until the 2.6 series, the way this worked is that if the second number was odd, it was a development release where features were being added and tested, and if it was even, then it was a stable release where features were more or less solid and only bugfixes would be released. With 2.6, that has basically been thrown out the window, with Linus saying that there won't be a 2.7 for a while, if ever, and instead new feature development will happen in the 2.6 branch. The third number indicates minor releases. Pre-2.6, this meant bugfixes only. Post-2.6, it has also included new features and such.

    As you can see, even in Linux the meaning has changed.

    For another example, we have Trolltech, the company that produces Qt. For them, again, the first number is a major revision -- totally breaks compatibility, complete rearchitecture. It also means they can break binary compatibility. The second number means they can add significant new features. The third number means a bugfix-only release, which must maintain binary compatibility.

    Yet another example is the KDE project. For them, major revision numbers (the first number) indicate they can break binary compatibility with their libraries, the kdelibs module. The second number allows binary compatibility breaks with their applications, but not their libraries. The third number is typically a bugfix release, but some features are sometimes backported from the next minor version (second number change) to a bugfix release.

    Finally, there's Rails. For them, the first number means that things that have been marked as deprecated are now removed, basically, and that things can more easily break. The second number changes with either minor or major feature additions. These sometimes do and sometimes don't have the potential for breaking other applications, but typically when they do it's not intentional (i.e., it's not because they removed a function or something, but rather because they upgraded to a newer version of a dependent library). The third number is still a bugfix release.

    In short, it depends on the project. Especially before a 1.0 release, which is typically when you first feel you have a solid product. Before that happens, a lot of people basically just randomly number their stuff :-P


Remove Ads

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT -6. The time now is 06:17 AM.
Powered by vBulletin® Version 4.2.3
Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.
vBulletin Skin By: PurevB.com