-
Notifications
You must be signed in to change notification settings - Fork 34
Developers Guide
Creating an Issue before doing any development is a good way to foster discussion and keep commits well-organized. No Issue is too small! Issues can also be used in cases where you aren't certain if there is support for a change - creating an Issue will bring the developers together to focus on a single topic.
- Try to make separate Issues for different concerns.
- Check the current Issue list as best you can before creating a new one - there are some commonly found Issues that just haven't been fixed yet.
If you are working on an Issue, and plan to have it done before the next release, change it's Milestone to the most recent one so we can more easily keep track of them.
There are a bunch of tags you can use to organize your Issues. They aren't critical, but they certainly add colour to the board!
As best you can, try to make your Pull Request description very readable. We're interested in reading about why you made a change, not how. If there are any hacks, or points in the code that you weren't sure of, please point them out too!
If you need to edit settings.php or settings_1.php to make your feature work, be sure to make the other areas neutral before you make your pull request.
If you aren't changing these files, be sure to set them assume-unchanged like this:
git update-index --assume-unchanged settings.php
git update-index --assume-unchanged localsettings\settings_1.php
Or if you use TortoiseGit, set Skip Worktree on the file.
We're using Travis CI (https://travis-ci.org/TheNAF/naflm) to automatically deploy committed code to http://thenafdev.obblm.com/. This will run almost immediately after commit, but it give some time before checking.
We should be doing full deployments to http://thenaf.obblm.com/ when we're comfortable with the code. There isn't, and should not be, an automatic deployment here.
As of 1.1, there is code to check and automatically run SQL upgrade scripts. In the 1.1 release, admins will log into the system and NAFLM will run through every upgrade script from 075 onwards. In the 1.2 release and any future releases, SQL upgrade scripts will be run automatically upon first login by an admin, and will only run those scripts from the last known version to the current one.
The database upgrade code checks to see if the current database version (found in the database table version) is less than the stated database version (found in settings_default.php).
For development, this condition will never be true after the first deployment. Because of this, developers doing SQL upgrades will have to manually run the upgrade.php script on thenafdev to have their changes seen in the database.
Ensure your SQL upgrade scripts can be run more than once.
/lib/mysql_upgrade_queries.php has a variable $upgradeSQLs that is a list of versions. If you need an upgrade script run, add your script text to the version we're currently developing for. So if we were working on version 1.1, you would add to the list 101.
Ensure that you number future database upgrade versions only by the "to" number, and ensure they are integers. Previous upgrades had "from-to", and this is not as helpful as simply "to".
Ensure that settings_default.php has the number of $db_version updated to the version of NAFLM that is being deployed. This number must always be increasing! NAFLM 1.0 is 100, NAFLM 1.1 is 101, etc.