Torque 3D Versioning Questions

#1 I vote for a time stamp. Something as simple as Year and Month would work. Could be Feb 2013 like directX or 13.02 like ubuntu.

#2 Normally, I'm against Year and Month. This was nothing but a major source of confusion in past engine releases for T3D. However, it does make more sense for the open source project. I think UDK and DX do a great job, considering the frequency. It also avoids the debate of "what qualifies for X.X". It's just a plain and simple statement of a build.

So my vote is the time stamp, Month_Year. That's what I want to use for T2D MIT, but I also want T2D to be as close to T3D as possible when it comes to operations.

#3 The DirectX approach was propossed by Daniel B., and I gree with it too.

However I was hoping that the guys at the comitee comment on this first, as it could be that they had a very valid reason why to go with this scheme, and then we would just go on with it.

#4 Thanks, Eric.

Version numbers have come up twice now. The first was back in October as part of a Committee meeting: Committee Meeting Notes: 10/2/2012 and the second here in December: Torque 3D Open Source Update 2012-12-13 (check the comments).

- Dave

#5 Im missing something?

The first link, Committee Meeting Notes: 10/2/2012 seems to have some objections to the propossed scheme, but no one answers.

The second, well, I only read a comment saying it would be labelled 2.0

#6 semver.org

Semantic versioning is useful. You can see at a glance if an update breaks anything. For a bugfix update you just update the last number. For new features which don't break anything you update the middle one and put the last one to zero. For a major release which is likely to break things you bump the first number up and set the other two to zero. Simple and understandable.

It could easily be combined with a computer date for sorting: YYYY-MM-DD.x.y.z should sort nicely and tell you what sort of release it is, and when. But for something with frequent updates "forever" I'm not sure a date is necessary in any other places than the changelog.

#7 OK, onto why we chose what we did.

We decided that each release would be a major number, where a release is when we push to the master branch. Any point release would then be a hot fix where we broke something that we want to get out before the next release. So that makes this release in December 2012 v2.0. Our next release would be 3.0, etc.

We could continue with the commercial numbering of T3D's versions and release as 1.3, 1.4, etc, but then it sounds like we're leading up to a 2.0 which implies something big. We don't have those kinds of resources to lead up to something big, unless we intentionally hold something back to make an artificial "bigness". We don't have some people working on just bug fixes while the rest of the team work on the next big feature -- that's the retail business. We're doing it all, all the time.

We're aiming for three or four major releases a year (that's how we've grouped our road map that we'll be presenting to the community). So at the end of 2013 if we have three releases we'll be at version 5.0. At the end of 2014 we will be at v8.0. And at the end of 2015 we'll be at v11.0.

We could have gone with a date-like format, such as YY-MM or YY-MM-DD. I did that with my LightWave exporter. Then it looks like you're only rolling over a major version number each year for those that are concerned we're going too fast.

But now where does hot fixing fit in? If we go with the full date format of YY-MM-DD then we could just make the hot fix version be the date we release it on. Although I'm not sure how this would tell people this is a hot fix and not a major release. We could also tack on a version number to the date such as YY-MM r1 for the first hot fix (or r2 if r1 is the actual major release) but now we're mixing metaphors, aren't we? Is this less confusing to people than major.hotfix?

- Dave

#8 Some really good points Dave. I should go back to my code cave and reconsider my opinion when it comes time to prep T2D =)

#9 Really it makes a much more sense now.

I would comment this, however: there seems really unnnecessary to increase the major version number, jut to allow people understand whats a hotfix, and whats a release.

Maybe hotfixes should labelled, simply "Hotfix 1 for release December 2012".

#10 @Dave,
The versioning change annoyed me at first. Most likely because of the Firefox change. I didn't have a real reason to be annoyed though. Nor with Firefox version change.

Now that I see this is part of officially breaking away from the commercial release paradigm this makes a lot of sense. There is not reason to build up to a major release as you are not trying to up sales for that release. I like how it signifies the dev branch to master brand flush. That is as good a reason as any to update the major revision.

It also will help with telling what version 3rd party addons work with. You don't have to say: Is it version 1.2 or 1.2 MIT? So now you can just say is it <2.0 or >2.0? This is a good thing as things move forward.

I see one potential issue with it though. How can you tell when an x.0 release breaks the API or is a major enough change that it operates differently that it breaks functionality? Perhaps it might help to introduce release names for a change like that? So the current codebase could be called Maya or something catchy. I know, I know, there is not perfect way to do this. In the end it does not really matter except for preference and practicality.

#11 Perhaps:
Master release # / Hot-Fix release #/ Bug-Fix # . YY-MM-DD

Similar to how the Public Library categorizes and then distills the thousands of books... minus the Dewey Decimal System. It's logical and easy to locate information.

#12 As long as the numbers keep going up and not down or stop moving all together we're happy over here. Keep it simple I say and keep up the good work!

#13 What about dice? I have lots of dice. We could roll them and then roll them again to see what order to put the first set of rolls in....

No?

Ok, then I vote for YY.MM too. But I really like the dice....

#14 YY.MM
If month ended up before year you'd get newer versions with lower a prefix number than older versions which would lead to confusion. Keep it ascending.

#15 Year and month isn't a good convention for version numbers, and really only works for long form names to avoid confusion between the differing date formats all over the world.

Plus, it would make things really confusing as currently the date is what I'm thinking of using for the unstable builds.

We couldn't get it going for this release for a few reasons, but in the future there will be downloads of the current, and maybe a previous or two, Stable builds based on master (version.hotfix) and Unstable nightly builds based on development (version.hotfix.yyyy.mm.dd or version.hotfix.yyyy-mm-dd).

What you'll end up seeing would be something along these lines:
Stable
2.0
1.1
1.0

Unstable
3.0.2013-01-01
3.0.2012-12-31
3.0.2012-12-30
3.0.2012-12-29
3.0.2012-12-28
3.0.2012-12-27
2.0.2012-12-26

I left that last one as 2 to show an example of the version incrementing. I'm thinking that we would probably let the version sit for a week or so to wait and see if a hotfix ended up being required. The majority of the time you won't see that number past 0.

#16 YY.MM you could even put a version number on the front as well if you want just to keep version numberer's happy (is that eve a word?) i.e.

VV.YY.MM but remember January is 01 and not 1 else sorting by date won't work properly

[edit]
ok I prefer the above post way :-)
[/edit]

#17 I think you are trying so hard to make clear whats a night build, whats a hotfix, whats stable and what not, that at the end:

a) you assume most people are total noobs that cannot read properly.
b) all ends up more complicated than it should be.

Seriously guys, Stable or nightly should be put in the title of the link, has little to do with the actual version number.

The version numbers are hardly something that could affect productivity, and moving away from commercial workflow is ok, but I think breaking the convention only creates cognitive dissonance, as with firefox.

Maybe moving away from version numbers altogether should be considered too. Maybe dates, but not with numbers and dots, actual words people: "Torque3D.Stable.December.20.2012."

#18 Torque 3d 1.2.0001 would have been more appropriate.

#19 If you consider the enormous amount of added features and bug fixes between T3D 1.1 and T3D 1.2, calling this release T3D 2.0 is a bit misleading.

#20 Maybe Torque3D.Stability.Year.Month.hotfix#

So like Torque3D.Stable.December.2012 or Torque3D.Stable.December.2012.Hotfix1 when a hotfix rolls along.