index.rst 3.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869
  1. Contributing
  2. ============
  3. Developing and testing coderedcms
  4. ---------------------------------
  5. To create a test project locally before committing your changes:
  6. #. Run ``pip install -e ./[dev]`` from the coderedcms directory. The -e flag makes the install editable,
  7. which is relevant when running makemigrations in test project to actually generate the migration
  8. files in the coderedcms pip package. The ``[dev]`` installs extras such as sphinx for generating docs.
  9. #. Follow steps 4 through 6 in :doc:`/getting_started/index`. Use "testproject" or "testapp" for
  10. your project name to ensure it is ignored by git.
  11. #. When making model or block changes within coderedcms, run ``makemigrations coderedcms`` in the
  12. test project to generate the relevant migration files for the pip package. ALWAYS follow steps
  13. 4 and 5 in :doc:`/getting_started/index` with a fresh database before making migrations.
  14. #. When model or block changes affect the local test project (i.e. the "website" app), run
  15. ``makemigrations website`` in the test project to generate the relevant migration files locally.
  16. Apply and test the migrations. When satisfied, copy the new migration files to the
  17. ``project_template/website/migrations/`` directory.
  18. When making changes that are potentially destructive or backwards incompatible, increment the minor
  19. version number until coderedcms reaches a stable 1.0 release. Each production project that uses
  20. coderedcms should specify the appropriate version in its requirements.txt to prevent breakage.
  21. Contributor guidelines
  22. ----------------------
  23. We are happy to accept pull requests from the community if it aligns with our vision for coderedcms.
  24. When created a pull request, please make sure you include the following:
  25. * A description in the pull request of what this change does and how it works.
  26. * Reference to an issue if the change is related to one of the issues on our github page.
  27. * Documentation updates describing your change.
  28. Following submission of your pull request, a CodeRed member will review and test your change.
  29. **All changes, even by CodeRed members, must go through a pull request process to ensure quality.**
  30. Building pip packages
  31. ---------------------
  32. To build a publicly consumable pip package and upload to pypi, run::
  33. python setup.py sdist bdist_wheel
  34. twine upload dist/*
  35. Building & publishing documentation
  36. -----------------------------------
  37. For every code or feature change, be sure to update the docs in the repository. To build and publish
  38. the documentation run::
  39. cd docs/
  40. make clean
  41. make html
  42. Output will be in ``docs/_build/html/`` directory. To publish:
  43. * If updating docs for an existing minor version release:
  44. #. Copy the contents of ``docs/_build/html/`` to the CodeRed docs server under the existing version directory.
  45. * If this is a new major or minor version release:
  46. #. Create a new major.minor directory on the CodeRed docs server.
  47. #. Update the ``.htaccess`` file to point to the new version directory.
  48. #. Add the new version to the ``versions.txt`` file on the docs server.
  49. #. Copy the contents of ``docs/_build/html`` to the CodeRed docs server under the new version directory.
  50. Note that we do not release separate documentation for maintenance releases. Just update the existing minor
  51. version docs if there are any maintenance release doc changes.