New Post: Composite C1 5.0 Beta 1 released

@burningice, the reason we would like to hear peoples pain points is to understand them and figure out how we can best go about distributing updates. Purely manual guides are error prone and errors cause grief and more support at our end.

An example could be structural changes across config files - rather than writing a (rather tedious) description of what attributes to rename, values to modify etc. we would prefer to deliver a script that can make the needed transformations and keep the guide boiled down to "check out files, x, y and z if needed - run the tool - check in files x, y, z". We have done this in the past (published an XSLT along a manual upgrade guide).

I think most developers preference towards doing an upgrade is more "make it easy and robust, fitting my environment" rather than "make me manually do every single change".

You spend time once on the guide, but can still sell it many times, instead of having to be in direct touch with n developers in regards to y solutions.

We might be misunderstanding each other. We'd like to talk to developers who have issues with our current model, so we can adjust it to bring about the "make it easy and robust, fitting my environment" experience when upgrading. Once we've adjusted our tooling subsequent upgrades should ideally work smoothly in those environments. Asking people to execute tedious (and error prone) work, for every single solution, for each update we make, is what we would like to minimize.

No. Magic. Black. Boxes.

I guess this need is stemming from the fact you have sites running on a highly customized fork of the C1 code, which makes automation tricky. If you could simply "press a button", get perfectly upgraded and compare changes in git to see what changed, wouldn't you prefer that?