We still provide support for TS12. The choice to make use of that support or not is on you.
No, not at all. The failure to support my *in support* product is wholly on you. Once again, I'm going by both the product you advertised and marketed to me when I pre-purchased it well before it was released, the product as it's still marketed today, and the product I bought and your stated lifecycle policy. And they all say the exact same thing: It's TS12. There is nothing about revisions. Ultimately, that's all that matters.
I'm sorry, but that is exactly the reason. Validation helps to ensure that content actually works to some reasonable degree. It's not perfect, but it's a darn sight better than no validation at all.
And building content to a higher standard but setting a lower minimum Trainz-build has worked well for years. It may not be perfect, but it's a darn sight better than excluding paying customers who took you at your word and bought your product in good faith.
Holding yourself to a higher quality bar than is strictly required is certainly a noble goal, but there are two obvious problems with that approach:
1. If you build to a given standard, then back-date the version number, it's quite possible that your content will not actually run on the version number you claim. Eventually, we may have validation that is smart enough to pick up on this kind of problem, but so far our validation is focused on what causes problems for the current Trainz version, not for detecting possible problems with previous versions. For this reason we have never recommended back-dating content.
Then that is on you; it is your fault for not providing the proper validation, not your customers. Interestingly, Trainzers have been saying that for longer than I've been around. Perhaps you should listen.
Moreover, the few situations in which your assertion might possibly be true can be (and has been for years) generally addressed by content creators by building version- or level-specific items - sometimes just for one version, sometimes multiple versions, such as pre-TS12 and TS12 and up, for example. Unlike N3V, individual content creators did not write the marketing materials for Trainz, did not publish the lifecycle policy, and have no binding obligation to support any specific version or versions, or even to create content at all.
2. The validation code has no way to determine your support goals other than the trainz-build number. If you claim that you are building for 1.3, the validation code will have to take that at face value. This will means that a lot of checks are suppressed in the name of compatibility, which is not a good thing for anyone when we're talking about building new content. I guess this is where we could add a new tag, along the lines of "please validate me up to v4.1, but assuming I pass that, allow me to be used down to v3.1." This is actually quite reasonable and I'll mention it to the team, but it's not entirely trivial for us to implement (mostly because of point 1 above.)
Not sure why you didn't do that from the beginning but that's your problem, not mine. I'm not going to suffer the consequences of your lack of proper planning. You should become familiar with a saying that I learned in my flying days, but which is common in the business world as well: "A lack of proper planning on your part does not constitute an emergency on mine."
