Development and Contributing
============================

When contributing to this repository, please first discuss the change
you wish to make via issue, email, or any other method with the owners
of this repository before making a change.

Please note we have a code of conduct, please follow it in all your
interactions with the project.

Pull Request Process
--------------------

1. Ensure any install or build dependencies are removed before the end
   of the layer when doing a build.
2. Update the README.md with details of changes to the interface, this
   includes new environment variables, exposed ports, useful file
   locations and container parameters.
3. Increase the version numbers in any examples files and the README.md
   to the new version that this Pull Request would represent. The
   versioning scheme we use is `SemVer <http://semver.org/>`__.
4. You may merge the Pull Request in once you have the sign-off of two
   other developers, or if you do not have permission to do that, you
   may request the second reviewer to merge it for you.

Version Management
-------------------

We use `bump2version <https://github.com/c4urself/bump2version>`__ to manage
version numbers across the project. This ensures that version numbers are
updated consistently in all the right places.

**Installing bump2version:**

.. code-block:: bash

   pip install bump2version

**How it works:**

The project uses a ``setup.cfg`` file to configure bump2version. It automatically
updates version numbers in:

- ``setup.cfg`` (current_version)
- ``pyproject.toml`` (version field)
- ``drf_simple_apikey/version.py`` (VERSION constant)
- ``CHANGELOG.md`` (adds new version entry with date)

**Bumping versions:**

To bump the version, use one of these commands:

.. code-block:: bash

   # Bump patch version (2.2.1 → 2.2.2)
   bump2version patch

   # Bump minor version (2.2.1 → 2.3.0)
   bump2version minor

   # Bump major version (2.2.1 → 3.0.0)
   bump2version major

**What happens:**

1. Bump2version updates all version numbers in the configured files
2. It automatically creates a commit with the version bump
3. It creates a git tag for the new version
4. It updates the CHANGELOG.md with a new version entry

**Important notes:**

- Always update the CHANGELOG.md with the changes before bumping the version
- The CHANGELOG entry for the new version will be created automatically, but
  you need to add the actual changes under it
- After bumping, push both the commit and the tag: ``git push && git push --tags``

Code of Conduct
---------------

Our Pledge
~~~~~~~~~~

In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our
project and our community a harassment-free experience for everyone,
regardless of age, body size, disability, ethnicity, gender identity and
expression, level of experience, nationality, personal appearance, race,
religion, or sexual identity and orientation.

Our Standards
~~~~~~~~~~~~~

Examples of behavior that contributes to creating a positive environment
include:

-  Using welcoming and inclusive language
-  Being respectful of differing viewpoints and experiences
-  Gracefully accepting constructive criticism
-  Focusing on what is best for the community
-  Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

-  The use of sexualized language or imagery and unwelcome sexual
   attention or advances
-  Trolling, insulting/derogatory comments, and personal or political
   attacks
-  Public or private harassment
-  Publishing others’ private information, such as a physical or
   electronic address, without explicit permission
-  Other conduct which could reasonably be considered inappropriate in a
   professional setting

Our Responsibilities
~~~~~~~~~~~~~~~~~~~~

Project maintainers are responsible for clarifying the standards of
acceptable behavior and are expected to take appropriate and fair
corrective action in response to any instances of unacceptable behavior.

Project maintainers have the right and responsibility to remove, edit,
or reject comments, commits, code, wiki edits, issues, and other
contributions that are not aligned to this Code of Conduct, or to ban
temporarily or permanently any contributor for other behaviors that they
deem inappropriate, threatening, offensive, or harmful.

Scope
~~~~~

This Code of Conduct applies both within project spaces and in public
spaces when an individual is representing the project or its community.
Examples of representing a project or community include using an
official project e-mail address, posting via an official social media
account, or acting as an appointed representative at an online or
offline event. Representation of a project may be further defined and
clarified by project maintainers.

Attribution
~~~~~~~~~~~

This Code of Conduct is adapted from the `Contributor
Covenant <http://contributor-covenant.org>`__, version 1.4, available at
`http://contributor-covenant.org/version/1/4 <http://contributor-covenant.org/version/1/4/>`__