Often I see projects that have upgraded from e.g. v12 to v14 not upgrading the repository-data and/or site maven modules to latest structure. Which can give troubles upgrading to major versions.
I want to update the structure of now v14 project to v14 archetype structure. Now the site module did not run into problems, the repository-data module did.
In archetype you get a hst: but in the upgraded project I have a hst:hst. I can move configurations in the repository-data to preferred module but the project will not build correct local, no hst:hst is available.
So does Upgrading repository-data modules have added value?
If you have to migrate to hst:, how does production deployment play out? (e.g. will you have to save production documents and reload them)
I’m not quite sure I understand you, but I assume you mean in the repository? From thirteen onwards your hst:hst node becomes hst:myproject and hst:platform. You can still use hst:hst, but you need to specify that in a configuration file. Check our upgrade documentation here [1] (login required).
I don’t see how you will have hst: anywhere, so that is what confuses me.
We do recommend you upgrade to the latest structure, even when not strictly necessary. This will make it easier for newer developers as well as new functionality that may erroneously not take into account older structures. Also, documenation will generally be based on the latest version of the product. So this might also be confusing when your structures differ from what is seen in documentation.
Thanks for your reaction.
I’m sorry the text after hst: is missing. I meant:
If you have to migrate to hst:myproject, how does production deployment play out?
You have a repository based on hst:hst and your upgraded configuration code goes to hst:myproject. E.g. will you have to save production documents and reload them?
P.s. I agree on always upgrading to latest structure and am sorry to see that in most cases no time for that has been taken in to account. Which, in most cases, led to problems later on.
Right, so you don’t need to rename hst:hst, but you do need to configure that the hst root is on hst:hst rather than hst:myproject. See the documentation I linked above.