I'm wondering if there are any special guidelines for keeping up-to-date with limesurvey code changes by tracking the git repo. My thought is to create a fork of the master branch and apply my own changes to it (i.e. templates, config, my plugins if I have any), using the official Limesurvey git repo as an upstream remote. If there is an update to the stable branch on Github, I'll check out my master, merge in the upstream master, and push that to my production site.
Questions:
anyone see any problems with the above workflow?
What about db changes? How to make sure those get implemented if there are any after the update?
Thanks in advance for any replies.
Last edit: 10 years 6 days ago by chinaski01. Reason: grammar
In general I would not recommend to update directly from Git:
*We do not provide support for versions pulled directly from Git.
*It won't also include the build number as it is only included on release so you won't be able to update using ComfortUpdate anymore. ComfortUpdate also takes care of DB changes.
ComfortUpdate does not touch modified files - it will stop and warn.
User templates are kept in the /upload directory and not affected, too. The config isn't touched, too, same with plugins if kept in the right directory.
I don't use the ComfortUpdate (can't in my environment). I am currently updating Limesurvey core by downloading the latest stable release from the downloads page, creating a packaged release by adding my config, uploads, and plugins to it, and then pointing to this as the new source.
My question still is whether visiting the admin page after upgrade triggers a DB rebuild, if there are changes.
If it does, then it seems possible to track the project from the stable git repo.