Always use sub-stacks for third party plugins and libraries?

[Clarkey]

Hi folks,
Is it always best practice (with RunRev 4.0+) to deploy third-party plugins as sub-stacks under the app's main stack? I have read about some people preferring to leave components as independent stacks and using some kind of dummy sub-stack to manage links. Is this still a relevant approach and why/when/where would it be appropriate (and if so, how is it best achieved)?

I'm adding some bought custom controls that will have different change cycles to the app using them (think DataTree, ListMagic, etc.). I am also building some library files that I expect to need to update to reflect changes in the external systems with which they interact - perhaps involving 'hot-fixes' between app releases. However, I expect the overall payload of a full app update to remain relatively small. So, should I just use sub-stacks as a universal approach and just manage versions at the complete build level or do I need to be more careful in managing these components?

Any insights gratefully received.
Best,
Keith..

[mwieder]

I don't have a definitive answer for you, but as you noted, one of the advantages of using independent stacks is that you can update components individually without replacing the entire application simply by swapping in a new version of a component stack.

[Clarkey]

Thanks Mark, I'm sure this is one of the many aspects of Rev (and indeed broader systems architecture and development practice) where there is a lot of grey area between fixed rules, with room for personal choice and plenty of ifs, buts and maybes - and that flexibility is a good thing.

I've never managed the pain of product releases, so I'm really looking for any 'if... then' rules of thumb from those who have got their fingers burnt. I'm making enough original mistakes of my own to have no desire to repeat others' learning if I can avoid it!

I'm tempted to use a common approach throughout rather than mix embedding and linking. So, I'm tempted to keep things independent as a matter of course - even if that may be overcomplicating things(?)