what additional steps are necessary after deploying a new bazel release? I was experimenting with one of my decentralized networks (older 3.1 release) and simply removed everything via sftp and scp'd the bazel 3.4.5 code.
Accessing it throws 'This social network is still being set up!'
oh no....There are a lot of configuration files which you do NOT want to overwrite...particular the configuration XML files in /instances/ and the ones in /xn_private/.
I wrote blog entry describing the process I used. I'll update it in a couple days after I do the next big update on my network...
Thanks Hari Karam - it took my a while to process your posts and experiment with my networks.
I moved forward but I am not 100% successful yet.
I first experimented with a 3.1.2 decentralized network which I wanted to upgrade to a vanilla 3.3.6
My procedure using git as version control and cygwin command line tools was:
- scp code from decentralized network to my local machine
- init git repository with baseline code
- branch repo for upgrade
- download bazel-3.3.6.zip
- update lib, widgets, test and xn_resources/widgets directories from zip
- examine diffs between master and current branch
- merged changes into main branch
- ran AllUnittests.php before updating decentralized network
- sftp'd to ning server and removed lib, widgets, test and xn_resources/widgets
- scp lib, widgets, test and xn_resources/widgets from local machine to ning
- updated appVersionCode in two files: instances/main/widget-configuration.xml and xn_private/main-private-configuration.xml
- ran again AllUnittests.php after updating decentralized network
I was then able to access my network (unlike with my first brute-force approach) but I still have outstanding problems:
- dojo failed to load a file (embed.footer)
- some links (e.g. send message in mypage) fail to work (related to dojo/js problems)
- unable to see list of features under manage features
I was able to correct the dojo problem by adjusting the language in instances/main/widget-configuration.xml which I find a bit silly...
What I liked about your comments and this note is that we should be able to narrow down the deployment of bazel (ie library and accompanying resource) updates followed by our own patches/mods and components (mozels).
While this should be easy, I am not quite there yet unfortunately.
Be sure to erase files that are in the old version but NOT in the new version. Ning's MPC and templating structure auto includes files in certain folders, I've found. I had some lib files names _old.XN_Class.php and they were causing redefined class errors.
Also you got to really watch those instances/*.xml files AND the xn_private/*.xml files. Also realise that they contain redundant info some of which is accessed in the instances/* XML files but NOT the xn_private/*.xml files and vice versa.
While I appreciate Ning's power and flexibility and its openness, let me say for the record that I think it's totally inaccessible to all but the most experienced programmers. Clarity, simplicity and elegance seem to be lacking as the counterpoints to extensibility, scalability, and flexibility IMHO...
it requires indeed a lot of care... I second that.
Funny you mentioned that instances/*/*xml and xn_private/*xml - I just wrote that in my summary note as well.
There were some oddities with the Javascript (part of xn_resources) but I believe (unfortunately not quite sure here) that resetting the style through the web interface cleaned things up. I will keep you posted as our procedure gets better...