-
Notifications
You must be signed in to change notification settings - Fork 434
Release Procedure
please refer to https://github.com/ChurchCRM/CRM/wiki/The-Release-Process for the new release process
-
ChurchCRM Major (0.x.x) and Minor (x.0.x) releases will only occur on Monday, Tuesday, or Wednesday nights.
-
If the release is blocked by a P0 bug, then the release will be delayed until the next release window.
-
Release Candidates will be made available one week before the targeted release date.
-
ChurchCRM patch builds (x.x.0) may be released at any time, upon validation that the patch:
a. Fixes the issue for which it is intended
b. Does not introduce any new issues (or features)
c. Does not significantly alter the code base
- Cause database corruption.
- Prevents backup or restore the databse
- Expose sensitive data
- Prevents User Login
- App crashes
- Change to the ChurchCRM working directory, and destroy any existing vagrant boxes
```
vagrant destroy -f
```
- Checkout the branch to be released, and pull any updates
```
git checkout master
git pull
```
- Remove all extra files to ensure a clean build
```
git reset --hard
git clean -xdf
```
- Start the vagrant box to build all prerequisites. When build is complete, log into the box on SSH and cd to /vagrant
```
vagrant up
vagrant ssh
cd /vagrant
```
- Update the Languages files by running:
```
npm run locale-gen
```
This will create a new /src/locale/messages.po file. If you have access rights, upload this file to POEditor.com
- Pull updated translation strings from POEditor.com
First edit BuildConfig.json, and set ```POEditor.token``` to your personal POEditor API access token. Then, run:
```
npm run locale-download
```
- Check in translation file
1. Create a new branch from master
2. Commit changes to messages.po
3. Push the branch to GitHub
4. Merge the branch to Master. Note the commit hash - we'll want to compare this against the demosite later.
This testing should be done to ensure there are no last-minute "showstopper" bugs or a bad build
-
Test Build on Master http://demo.churchcrm.com/master
-
Test the zip file in the vagrant QA environment:
1. After creating the release zip archive, copy it to /vagrant-qa
2. Edit /vagrant-qa/VersionToLaunch. Place the filename as the only uncommented line of the file
3. From the /vagrant-qa directory, run
```
vagrant up
```
4. A new Vagrant VM wil be started on http://192.168.10.12 with the contents of the release zip. Test major functionality in this QA environment
5. After testing a clean install of the release, test an in-place upgrade of the release.
1. Place a restore of a previous version of ChurchCRM in the /vagrant-qa directory. The file must be named ```ChurchCRM-Database.sql```.
2. Run ```vagrant provision```, and the vagrant VM will be re-loaded with the database pre-staged
3. Attempt to log into the vagrant-qa box. The in-place upgrade routines should upgrade the database.
https://github.com/ChurchCRM/CRM/releases
- Ensure you select the correct branch, and that the current commit hash matches the commit you created in step 4.4
- Enter version # subject
- Select tag as commit
- Point to the change log
- download zip from http://demo.churchcrm.io master list
- Upload zip file
- Save the release as pre-release
After the tag has been created, update the change log and version number
npm run changelog-gen
grunt updateVersions
- Commit the changes to a new branch titled
<new-version-number>-starting
if your new version has a schema change. - Update git release so it points to the latest version in the change log
https://github.com/ChurchCRM/CRM/milestones
- Close version milestone
- Create next version milestone
- Create a new branch to merge master into develop
- Create a PR to get approval for the merge - sometimes regressions can sneak in here, so be careful!
- It's common for PO and JS files to see very many conflicts. In this case, it may be useful to re-run the download script. Ensure that the current develop version has terms tagged in POEdtor, or else the files will not be downloaded correctly
- Non-duplicate issues without an assigned milestoneL https://github.com/ChurchCRM/CRM/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone+-label%3Aduplicate