This identified the current version within the API itself.
Update the _version_ value in shotgun_api3/shotgun.py to the version you're releasing. This controls what version users will get when installing via pip. Update the version value in python-api/setup.py to match the version you are packaging. Think about a new user to the API trying to figure out how to use the features you're documenting. Examples are always good especially if this a new feature or method. Ensure that doc strings are updated in the code itself to work with Sphinx and are correctly formatted. Ensure any changes or additions to public methods are documented. Make sure the version number is filled out and correct. We try and keep this TBD until we're ready to do a release so it's easy to catch that it needs to be updated. Make sure the date of the release matches today. Try and match the language of previous change log messages. This is a required step in making changes to the API. If you notice something was done that wasn't added to the changelog, hunt down that engineer and make them feel guilty for not doing so. This may include changes you did not make so look at the commit history and make sure we don't miss anything. Add bullet points for any changes that have happened since the previous release. Update the Changelog in the HISTORY.rst file. To run all of the tests, use the shell script run-tests. This data will be manipulated by the tests, and should not be used for other purposes. The tests will add test data to your server based on information in your config. The server and script user values must be supplied in the tests/config file. test_api and test_api_long do require a ShotGrid instance, with a script key available for the tests. test_client and tests_unit use mock server interaction and do not require a ShotGrid instance to be available (no modifications to tests/config are necessary). This will exclude python 2- and 3-specific files in the /lib directory, preventing a failure from being reported by nose for compilation due to incompatible syntax in those files. This option tells nose to use our config file. Make sure to not forget the -config="nose.cfg" option. 
Tests can be run individually like this: nosetests -config="nose.cfg" tests/test_client.py.
A tests/config file (you can copy an example from tests/example_config). (Note: Running pip install -r tests/ci_requirements.txt will install this package). Additionally, when testing locally, tests should be run for both python 2 and python 3 to ensure changes won't break cross-compatibility.
0 kommentar(er)
