Mx2 versioning

About Monkey 2 Forums General Discussion Mx2 versioning

This topic contains 6 replies, has 4 voices, and was last updated by  Arjailer 1 year, 10 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #9641


    Many leading software are using versioning scheme like 2017.1.

    It helps to understand release date (is it important?) and how many big changes were made each year.

    When you download installer it show you full version with patches/fixes like 2017.1.0f2.

    Don’t know is it better than 1.1.06 for someone else.:)

    But if the version is whole mx2 (with mods not only lang features) then with mojo3d I expect to see v1.2.0 because it’s major change.

    And I don’t understand why there is zero in current version v1.1.06; v1.1.6 is easy and understandable for me.:)


    Mark Sibly

    > Many leading software are using versioning scheme like 2017.1.

    I’m OK with the current system – personally, I’d probably prefer just 1,2,3… etc, ie: there are no ‘small’ changes, and there are no ‘finished’ versions, it’s just an ongoing dev cycle and your ‘stable’ version might not even be the same as mine depending on which features you/we use.

    The reason I used 1.1.06 instead of 1.1.6 is because when I reached 1.0.9 and went to 1.0.10 I found it messed up the tag ordering at github due to string sorting. So for better or worse I went to a 1.1.01 system.

    IMO, the versioning system used isn’t *that* big a deal (sure many will disagree) although I now feel it’s a good idea to used a string sortable method purely for the sake of flexibility.



    I’ve never cared about version numbers, I’ve only gone with the flow on all projects I’ve joined.
    But why not just 1.6, 1.7 etc.?

    I’d love it if it were just the date though, so like todays (in Sweden) version would be 17.8.2 (year, month, day)
    It’s a version number and you get an idea of how old it is.
    I’m sure there are downsides to that though heh.


    Mark Sibly

    I’d be OK with dat but with padding 0’s so it’s string sortable, eg: 17.08.01



    Tag sorting is a good reason. But you can (or not?) bump the second number before the third become 10 or more. 🙂

    And there is a question – what rule do you use to bump the first and the second version numbers?


    Mark Sibly


    …all good questions…and exactly why I’d prefer 1,2,3,4,5,6,7…!



    Our product uses <year>.<day-of-year>.<build-that-day> for version/build numbers – so the first build done today would be 2017.222.1, next build today would be 2017.222.2 – that works well for us for identifying individual builds for testing etc – but not ever build gets released and for public releases we still use Product 4.3, Product 4.4, Product 5.0 etc so that the marketing department has an annual release to rally around.

    But I have to say that these days I’m a big fan of “just put the number up by one each time you put out a release” approach used by Chrome (though I know they don’t quite stick to that for small bug fixes).

    It would make it tricky (impossible?) for a marketing department to delineate “here’s this years big release that customers need to pay for” (which is why we don’t use it for our product), but if you have a free, continually evolving product then as a user I like that simplicity.

    Edit: But ultimately I don’t mind – version it how you want  🙂

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.