Jiwa

When the document said find the XML file inside the ZIP file, I wasn't expecting this expedition...

pricerc wrote:When the document said find the XML file inside the ZIP file, I wasn't expecting this expedition...

Yeah, we know it's a rather silly situation, and we recognise we need to improve that.

We've debated having all the standard plugins deployed to the file system as XML files - so in a /plugins folder they could all be in there and service release installs could update those in there, and then it's easy and obvious to discover where the latest plugins are - we didn't design around this because service releases are not supposed to have such changes, but since then management have bent, broken and tied into a pretzel all the rules and so here we are.

We were actually fortunate that we did choose to store the REST API plugin in the source folder of the IIS package, so at least that plugin gets updated when installing service releases. That decision was made very early on in the REST API development days, and was not intended to be how we deploy updates at all.

We've debated having all the standard plugins deployed to the file system as XML files - so in a /plugins folder they could all be in there and service release installs could update those in there, and then it's easy and obvious to discover where the latest plugins are

Sounds like a good idea, you already have the report cache that could act in a similar way in that you could update reports even though you would still have to refresh them into the database.

Mike.Sheen wrote:We've debated having all the standard plugins deployed to the file system as XML files - so in a /plugins folder they could all be in there and service release installs could update those in there, and then it's easy and obvious to discover where the latest plugins are

This has been implemented in DEV-9340