Tweet
Backwards compatibility between Valence versions
We typically install OS PTFs and software updates/upgrades on the DEV box first, let it simmer there for a few weeks before putting it on the PROD box. I do the same thing with all Valence updates.
I don't know how other shops develop and promote their Valence apps, but we develop all our apps on the DEV box in the Valence DEV instance, and promote them up the stack from DEV to QA (which is also on the DEV box) and from there, to the production instance. We strongly discourage developers from changing apps in any other instance but I've stopped shy of disabling NAB in those other instances.
My question is about compatibility, mostly about backwards compatibility since, as I explained above, the flow from DEV -> QA -> PROD will always be (worst case) from newer release to older release and never the other way around.
It is possible for an app (and I guess I am talking NAB apps for now) that was developed in DEV on 6.1 and exported to PROD on 6.0 to encounter compatibility issues? I can certainly see that a NAB app developed in 6.1 may not be modifiable with NAB 6.0, after all, NAB 6.0 doesn't know anything about Super Column headers that are new in 6.1 for instance. And that's really not an issue for me because I don't want people to maintain NAB apps in the production instance anyway. The question is: is there ever potential for a run time issue, running apps in an older version that were developed on a newer version? Also, consider helper RPG programs. They often use VV files and they are compiled against a Valence library that's (let's say) 6.1. Such programs are installed on production using our CMS, just like all other green screen programs. Which means that same helper program will be compiled by the CMS on the PROD box hitting VV files in a Valence instance that (let's say) 6.0.
To be clear, my question isn't about 6.0 versus 6.1. The question is about the Valence PROD instance being on version X and the Valence DEV instance being on version Y. I don't know if other companies are developing their apps in the same instance they run production in.
This might be a good topic for one of the monthly news letters: Considerations for applying Valence updates. Valence updates demystified! Best practices for Valence instance updates.
I don't know how other shops develop and promote their Valence apps, but we develop all our apps on the DEV box in the Valence DEV instance, and promote them up the stack from DEV to QA (which is also on the DEV box) and from there, to the production instance. We strongly discourage developers from changing apps in any other instance but I've stopped shy of disabling NAB in those other instances.
My question is about compatibility, mostly about backwards compatibility since, as I explained above, the flow from DEV -> QA -> PROD will always be (worst case) from newer release to older release and never the other way around.
It is possible for an app (and I guess I am talking NAB apps for now) that was developed in DEV on 6.1 and exported to PROD on 6.0 to encounter compatibility issues? I can certainly see that a NAB app developed in 6.1 may not be modifiable with NAB 6.0, after all, NAB 6.0 doesn't know anything about Super Column headers that are new in 6.1 for instance. And that's really not an issue for me because I don't want people to maintain NAB apps in the production instance anyway. The question is: is there ever potential for a run time issue, running apps in an older version that were developed on a newer version? Also, consider helper RPG programs. They often use VV files and they are compiled against a Valence library that's (let's say) 6.1. Such programs are installed on production using our CMS, just like all other green screen programs. Which means that same helper program will be compiled by the CMS on the PROD box hitting VV files in a Valence instance that (let's say) 6.0.
To be clear, my question isn't about 6.0 versus 6.1. The question is about the Valence PROD instance being on version X and the Valence DEV instance being on version Y. I don't know if other companies are developing their apps in the same instance they run production in.
This might be a good topic for one of the monthly news letters: Considerations for applying Valence updates. Valence updates demystified! Best practices for Valence instance updates.
Comment