Any problem building Flare 10 project in Flare 9?

[kevinmcl]

All,

Writers at this location use Flare 10, mostly because we have Bronze maintenance and new versions are included... and we don't want to get behind the versions that are actively supported with fixes.
In other words, we don't intentionally use any newer features/functionality of Flare that were not in version 9. But that's not to say that Flare 10 mightn't be doing stuff under the hood that could insert stuff in our project files that Flare 9 wouldn't know about. Does it? Could it?

We have scripted nightly build-publish events, and all is well. Here.

However, the company has another development center elsewhere in the world, that takes the product developed here and adds integrations and some further development for specific market requirements. They also take our released customer documentation source files and update them to include the outcome of their product development additions.
Those writers are still using Flare 9. They have a more conservative tool-update schedule than we do.

Is there any danger that the Flare 10-produced documents might contain any code that is unsupported in Flare 9 and therefore give our across-the-pond gang any problems either with in-project editing/updates or with building/publishing?

I've opened my current project in Flare 9 and built output without obvious problem, but I wonder if that could change.

All we do at either location is create WebHelp/HTML5-ish help and equivalent PDFs. No other output.

Everybody at both locations uses Windows 7. Flare 10.2.1 here

Oh, and FWIW, we users of Flare 10 see intermittent crashes "MadCap Flare V10 encountered a problem."
The latest one I've seen was "Root element is missing"... rather scary...
The people using Flare 9 have NOT reported such crashes. Their conservative approach might have merit.

[RamonS]

Can't give any first hand experience, but as with any development tool, make everyone use the same version. I doubt the developers use version A at one site and version B at the other. While there are valid reasons not to go with the latest version at all times (as you found out assuming it has to do with version 10) there really is no good reason to vary between development environments unless you are keen on running into trouble. MadCap never claimed to support backward compatibility and on occasion explicitly advised against it. It might work, but it is not worth the risk.
The other office might be fine hanging back with upgrades if all they do is take existing projects and keep working on them. There will be a necessary delay in upgrading, but once the new projects are created in a newer version they should move forward. My suggestion is to manage this a bit better than trying to push your luck hoping that a v10 project will work fine with v9. At times Flare needs changes in the file structure of a project even when you do not use any of the new features.

[kevinmcl]

Hmm.

In the past, I've mostly upgraded within a month or two of a new whole-integer release... as soon as the flurry dies down and either there aren't any deal-killers or they've released the first dot-increment release to patch the opening-day glitches. So, maybe I've just never noticed MadCap releasing further dot releases of (say) 9.x, once 10.x is in play. I was under the impression that once a new major release came out, the old major was dropped like a dead thing, and would never see further security, compatibility, or workability fixes (like for memory leaks and other faux pas). Have I been wrong on that?

[RamonS]

I still think that is the case. As far as what gets supported how long and why, ask MadCap directly. Not sure why that would help with the version incompatibilities. As long as I can recall the word is not to expect that higher version projects work with lower versions. If they do, then it is more lucky coincidence than by design.

[kevinmcl]

Yeah... it doesn't help with between-version compatibility... at least not directly. Just sayin' there are reasons, in general, to keep moving forward with the product versions, that don't necessarily have to do with newer, fancier features.

And, in a distributed environment, where groups report to different organizations in different parts of the world, in different countries, cultures, and timezones, it sometimes takes a little nudge to persuade other groups to keep up.

Knowing that other forum members had experienced specific incompatibilities between Flare 9 and Flare 10, while - at the same time - our group had had 7 months of Flare 10 with only moderate problems, we would have had a good argument for the distant publication group to catch up with us, rather than for us to wait and wait and wait on them. We'd tell them that our next big release was coming down the pipe in two or three months, in Flare 10 source, and they'd better be ready.

But as it turns out, nobody seems to be reporting ANY intergenerational problems, so it might be a non-issue.
Or, at least that's what I'd conclude in an ordinary week. This time, however, I'll hold off concluding anything based on forum responses (or more accurately lack of such) until the USA staggers back to work following their biggest holiday of the year.

What I might do, after we get Flare 11 and try it for a while, is suggest that the other group just jump from 9 to 11, skipping 10 altogether.

On a somewhat un-related thought, that confrontation might be a while in the future, since MadCap has abandoned the old policy that a year of maintenance contract meant at least one full-integer upgrade included. So, now it's one-and-a-half? ... two years of maintenance gets you an included full-version upgrade? On the one hand it feels like losing some value for the money. On the other hand, if it means they are taking the extra time between releases to do more qualification and testing and to get it right before releasing (including existing functionality, not just new features), then it's a very worthwhile tradeoff. If. Ahem. <coff-featuritis-coff-coff>

[NorthEast]

I guess it depends on what you consider to be a problem.

Does it matter that the output built from v9 will be different to v10?
Whether the project originates from v9 or v10, when you build it in v9 and v10, you will get different outputs from each.

For example, if a new feature in v10 is enabled by default (like responsive output), whilst you may not explicitly select that option, it will still cause the outputs to be different in v10 and v9. There will also be differences behind the scenes that you can't control, e.g. HTML5 help built from v9 and v10 will behave differently in browsers, due to differences in the javascript and CSS.

At the end of the day though, if you're not using v10 features, then why not just use v9 for those projects that you're sharing?