diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index aa3eea6e9..d6fc540f9 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -58,15 +58,15 @@ Ready to contribute? Here's how to set up `cookiecutter-pypackage` for local dev
 
    .. code-block:: bash
 
-    $ cd path_for_the_repo
-    $ git clone git@github.com:YOUR_NAME/cookiecutter-pypackage.git
+    cd path_for_the_repo
+    git clone git@github.com:YOUR_NAME/cookiecutter-pypackage.git
 
 #. Assuming you have virtualenv installed (If you have Python 3.8+ this should already be there), you can create a new environment for your local development by typing:
 
    .. code-block:: bash
 
-        $ virtualenv cookiecutter-pypackage-env
-        $ source cookiecutter-pypackage-env/bin/activate
+        virtualenv cookiecutter-pypackage-env
+        source cookiecutter-pypackage-env/bin/activate
 
    This should change the shell to look something like:
 
@@ -78,7 +78,7 @@ Ready to contribute? Here's how to set up `cookiecutter-pypackage` for local dev
 
    .. code-block:: bash
 
-        $ git checkout -b name-of-your-bugfix-or-feature
+        git checkout -b name-of-your-bugfix-or-feature
 
    Now you can make your changes locally.
 
@@ -86,27 +86,27 @@ Ready to contribute? Here's how to set up `cookiecutter-pypackage` for local dev
 
    .. code-block:: bash
 
-        $ flake8 ./tests
+        flake8 ./tests
 
 #. The next step would be to run the test cases. `cookiecutter-pypackage` testing uses the `pytest` framework. Before you run `pytest` you should ensure all dependencies are installed:
 
    .. code-block:: bash
 
-        $ pip install -r requirements_dev.txt
-        $ pytest ./tests
+        pip install -r requirements_dev.txt
+        pytest ./tests
 
    If you get any errors while installing cryptography package (something like `#include <openssl/aes.h>`). Please update your pip version and try again:
 
    .. code-block:: bash
 
         # Update pip
-        $ pip install -U pip
+        pip install -U pip
 
 #. Before raising a pull request you should also run tox. This will run the tests across different versions of Python:
 
    .. code-block:: bash
 
-        $ tox
+        tox
 
    If you are missing flake8, pytest and/or tox, just `pip install` them into your virtualenv.
 
@@ -116,9 +116,9 @@ Ready to contribute? Here's how to set up `cookiecutter-pypackage` for local dev
 
    .. code-block:: bash
 
-        $ git add .
-        $ git commit -m "Your detailed description of your changes."
-        $ git push origin name-of-your-bugfix-or-feature
+        git add .
+        git commit -m "Your detailed description of your changes."
+        git push origin name-of-your-bugfix-or-feature
 
 #. Submit a pull request through the GitHub website.
 
@@ -146,27 +146,27 @@ To write and run your new test, follow these steps:
 
    .. code-block:: bash
 
-        $ git stash
-        $ git stash list
+        git stash
+        git stash list
 
 #. Run your test and confirm that your test fails. If your test does not fail, rewrite the test until it fails on the original code:
 
    .. code-block:: bash
 
-        $ pytest ./tests
+        pytest ./tests
 
 #. (Optional) Run the tests with tox to ensure that the code changes work with different Python versions:
 
    .. code-block:: bash
 
-        $ tox
+        tox
 
 #. Proceed work on your bug fix or new feature or restore your changes. To restore your stashed changes and confirm their restoration:
 
    .. code-block:: bash
 
-        $ git stash pop
-        $ git stash list
+        git stash pop
+        git stash list
 
 #. Rerun your test and confirm that your test passes. If it passes, congratulations!
 
diff --git a/Makefile b/Makefile
index ae0c0155e..1350d5fb8 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,5 @@
-BAKE_OPTIONS=--no-input
+BAKE_OPTIONS ?= --no-input
+NO_CRUFT = generated_with_cruft=n
 
 help:
 	@echo "bake 	Generate project using defaults"
@@ -6,17 +7,17 @@ help:
 	@echo "test 	Run the tests"
 	@echo "replay 	Replay last cookiecutter run and watch for changes"
 	@echo "watch 	Generate project using defaults and watch for changes"
-	
+
 
 bake:  # Generate project using defaults
-	cookiecutter $(BAKE_OPTIONS) . --overwrite-if-exists
+	cookiecutter $(BAKE_OPTIONS) . --overwrite-if-exists $(NO_CRUFT)
 
 watch: bake
-	watchmedo shell-command -p '*.*' -c 'make bake -e BAKE_OPTIONS=$(BAKE_OPTIONS)' -W -R -D \{{cookiecutter.project_slug}}/
+	watchmedo shell-command -p '*.*' -c 'make bake -e BAKE_OPTIONS=$(BAKE_OPTIONS)' -W -R -D \{{cookiecutter.project_slug}}/ $(NO_CRUFT)
 
 replay: BAKE_OPTIONS=--replay
 replay: watch
 	;
 
 test:
-	pytest
\ No newline at end of file
+	pytest
diff --git a/cookiecutter.json b/cookiecutter.json
index 9e9e24eec..93e7d6920 100644
--- a/cookiecutter.json
+++ b/cookiecutter.json
@@ -24,5 +24,24 @@
       "Not open source"
   ],
   "generated_with_cruft": "y",
-  "__gh_slug": "{{ cookiecutter.github_username }}/{{ cookiecutter.project_slug }}"
+  "__gh_slug": "{{ cookiecutter.github_username }}/{{ cookiecutter.project_slug }}",
+  "__prompts__": {
+      "full_name": "Your full name",
+      "email": "Your email address",
+      "github_username": "Your GitHub username (or organization)",
+      "project_name": "The name of your project",
+      "project_short_description": "A short description of your project",
+      "pypi_username": "Your PyPI username (or organization)",
+      "version": "The version of your project",
+      "use_pytest": "Do you want to use pytest?",
+      "use_black": "Do you want to use Black for code formatting?",
+      "use_conda": "Do you want to add configurations for Anaconda package management?",
+      "add_pyup_badge": "Do you want to add a pyup.io badge? (not recommended)",
+      "make_docs": "Do you want to generate documentation files",
+      "add_translations": "Do you want to add translations?",
+      "command_line_interface": "Which command-line interface do you want to use?",
+      "create_author_file": "Do you want to create an AUTHORS.rst file?",
+      "open_source_license": "Which open-source license do you want to use?",
+      "generated_with_cruft": "Was this project generated with Cruft? (Add a '.cruft.json' file)"
+  }
 }
diff --git a/tests/test_bake_project.py b/tests/test_bake_project.py
index 6cec49a0c..a5df6ab40 100644
--- a/tests/test_bake_project.py
+++ b/tests/test_bake_project.py
@@ -186,7 +186,7 @@ def test_bake_without_author_file(cookies):
         # Assert there are no spaces in the toc tree
         docs_index_path = result.project_path.joinpath("docs/index.rst")
         with open(str(docs_index_path)) as index_file:
-            assert "contributing\n   changes" in index_file.read()
+            assert "releasing\n   changes" in index_file.read()
 
         # Check that
         pyproject_path = result.project_path.joinpath("pyproject.toml")
diff --git a/{{cookiecutter.project_slug}}/CHANGELOG.rst b/{{cookiecutter.project_slug}}/CHANGELOG.rst
new file mode 100644
index 000000000..d7aa74c7c
--- /dev/null
+++ b/{{cookiecutter.project_slug}}/CHANGELOG.rst
@@ -0,0 +1,27 @@
+=========
+Changelog
+=========
+
+`Unreleased <https://github.com/{{ cookiecutter.github_username }}/{{ cookiecutter.project_slug }}>`_ (latest)
+{{ '-' * ('`Unreleased <https://github.com/' + cookiecutter.github_username + '/' + cookiecutter.project_slug + '>`_ (latest)')|length }}
+
+Contributors:
+
+Changes
+^^^^^^^
+* No change.
+
+Fixes
+^^^^^
+* No change.
+
+.. _changes_{{ cookiecutter.version }}:
+
+`v{{ cookiecutter.version }} <https://github.com/{{ cookiecutter.github_username }}/{{ cookiecutter.project_slug }}/tree/{{ cookiecutter.version }}>`_
+{{ '-' * ('`v' + cookiecutter.version + ' <https://github.com/' + cookiecutter.github_username + '/' + cookiecutter.project_slug + '/tree/' + cookiecutter.version + '>`_')|length }}
+
+Contributors: {{ cookiecutter.full_name }} `{{ cookiecutter.github_username }} <https://github.com/{{ cookiecutter.github_username }}>`_
+
+Changes
+^^^^^^^
+* First release on PyPI.
diff --git a/{{cookiecutter.project_slug}}/CHANGES.rst b/{{cookiecutter.project_slug}}/CHANGES.rst
deleted file mode 100644
index 148566b36..000000000
--- a/{{cookiecutter.project_slug}}/CHANGES.rst
+++ /dev/null
@@ -1,8 +0,0 @@
-=========
-Changelog
-=========
-
-{{ cookiecutter.version }} ({% now 'local' %})
-{% for _ in cookiecutter.version %}-{% endfor -%}-----------
-
-* First release on PyPI.
diff --git a/{{cookiecutter.project_slug}}/CONTRIBUTING.rst b/{{cookiecutter.project_slug}}/CONTRIBUTING.rst
index 2ac004c7c..d24e462b9 100644
--- a/{{cookiecutter.project_slug}}/CONTRIBUTING.rst
+++ b/{{cookiecutter.project_slug}}/CONTRIBUTING.rst
@@ -1,5 +1,3 @@
-.. highlight:: shell
-
 ============
 Contributing
 ============
@@ -62,8 +60,10 @@ Get Started!
 
     Anaconda Python users: Due to the complexity of some packages, the default dependency solver can take a long time to resolve the environment. Consider running the following commands in order to speed up the process::
 
-        $ conda install -n base conda-libmamba-solver
-        $ conda config --set solver libmamba
+   .. code-block:: console
+
+        conda install -n base conda-libmamba-solver
+        conda config --set solver libmamba
 
     For more information, please see the following link: https://www.anaconda.com/blog/a-faster-conda-for-a-growing-community
 
@@ -76,73 +76,84 @@ Ready to contribute? Here's how to set up ``{{ cookiecutter.project_slug }}`` fo
 #. Fork the ``{{ cookiecutter.project_slug }}`` repo on GitHub.
 #. Clone your fork locally::
 
-    $ git clone git@github.com:your_name_here/{{ cookiecutter.project_slug }}.git
+   .. code-block:: console
+
+    git clone git@github.com:your_name_here/{{ cookiecutter.project_slug }}.git
 
 #. Install your local copy into a development environment. {% if cookiecutter.use_conda == 'y' -%}
 
   You can create a new Anaconda development environment with::
 
-    $ conda env create -f environment-dev.yml
-    $ conda activate {{ cookiecutter.project_slug }}
-    $ flit install --symlink
+   .. code-block:: console
+
+    conda env create -f environment-dev.yml
+    conda activate {{ cookiecutter.project_slug }}
+    make dev
   {%- else -%}
 
   Using ``virtualenv`` (``virtualenvwrapper``), you can create a new development environment with::
 
-    $ python -m pip install flit virtualenvwrapper
-    $ mkvirtualenv {{ cookiecutter.project_slug }}
-    $ cd {{ cookiecutter.project_slug }}/
-    $ flit install --symlink
+   .. code-block:: console
+
+    python -m pip install virtualenvwrapper
+    mkvirtualenv {{ cookiecutter.project_slug }}
+    cd {{ cookiecutter.project_slug }}/
+    make dev
   {%- endif %}
 
   This installs ``{{ cookiecutter.project_slug }}`` in an "editable" state, meaning that changes to the code are immediately seen by the environment.
 
-#. To ensure a consistent coding style, install the ``pre-commit`` hooks to your local clone::
-
-    $ pre-commit install
+#. To ensure a consistent coding style, ``make dev`` also installs the ``pre-commit`` hooks to your local clone::
 
   On commit, ``pre-commit`` will check that{% if cookiecutter.use_black == 'y' %} ``black``, ``blackdoc``, ``isort``,{% endif %} ``flake8``, and ``ruff`` checks are passing, perform automatic fixes if possible, and warn of violations that require intervention. If your commit fails the checks initially, simply fix the errors, re-add the files, and re-commit.
 
   You can also run the hooks manually with::
 
-    $ pre-commit run -a
+   .. code-block:: console
 
-  If you want to skip the ``pre-commit`` hooks temporarily, you can pass the ``--no-verify`` flag to `$ git commit`.
+    pre-commit run -a
+
+  If you want to skip the ``pre-commit`` hooks temporarily, you can pass the ``--no-verify`` flag to `git commit`.
 
 #. Create a branch for local development::
 
-    $ git checkout -b name-of-your-bugfix-or-feature
+   .. code-block:: console
+
+    git checkout -b name-of-your-bugfix-or-feature
 
   Now you can make your changes locally.
 
 #. When you're done making changes, we **strongly** suggest running the tests in your environment or with the help of ``tox``::
 
-    $ make lint
-    $ make test
-    Or
-    $ make test-all
-    Or
-    $ python -m tox
+   .. code-block:: console
+    make lint
+    python -m pytest
+    # Or, to run multiple build tests
+    python -m tox
 
 #. Commit your changes and push your branch to GitHub::
 
-    $ git add .
-    $ git commit -m "Your detailed description of your changes."
-    $ git push origin name-of-your-bugfix-or-feature
+   .. code-block:: console
 
-  If ``pre-commit`` hooks fail, try re-committing your changes (or, if need be, you can skip them with `$ git commit --no-verify`).
+    git add .
+    git commit -m "Your detailed description of your changes."
+    git push origin name-of-your-bugfix-or-feature
+
+  If ``pre-commit`` hooks fail, try re-committing your changes (or, if need be, you can skip them with `git commit --no-verify`).
 
 #. Submit a `Pull Request <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request>`_ through the GitHub website.
 
 #. When pushing your changes to your branch on GitHub, the documentation will automatically be tested to reflect the changes in your Pull Request. This build process can take several minutes at times. If you are actively making changes that affect the documentation and wish to save time, you can compile and test your changes beforehand locally with::
 
+   .. code-block:: console
+
     # To generate the html and open it in your browser
-    $ make docs
+    make docs
     # To only generate the html
-    $ make autodoc
-    $ make -C docs html
+    make autodoc
+    make -C docs html
     # To simply test that the docs pass build checks
-    $ python -m tox -e docs
+    python -m tox -e docs
 
 #. Once your Pull Request has been accepted and merged to the ``main`` branch, several automated workflows will be triggered:
 
@@ -168,126 +179,25 @@ Tips
 
 To run a subset of tests::
 
+   .. code-block:: console
+
 {% if cookiecutter.use_pytest == 'y' -%}
-    $ pytest tests.test_{{ cookiecutter.project_slug }}
-{% else %}
-    $ python -m unittest tests.test_{{ cookiecutter.project_slug }}
+    pytest tests.test_{{ cookiecutter.project_slug }}
+{%- else -%}
+    python -m unittest tests.test_{{ cookiecutter.project_slug }}
 {%- endif %}
 
 To run specific code style checks::
 
-    $ black --check {{ cookiecutter.project_slug }} tests
-    $ isort --check {{ cookiecutter.project_slug }} tests
-    $ blackdoc --check {{ cookiecutter.project_slug }} docs
-    $ ruff {{ cookiecutter.project_slug }} tests
-    $ flake8 {{ cookiecutter.project_slug }} tests
+   .. code-block:: console
 
-To get ``black``, ``isort``, ``blackdoc``, ``ruff``, and ``flake8`` (with plugins ``flake8-alphabetize`` and ``flake8-rst-docstrings``) simply install them with `pip` {% if cookiecutter.use_conda == 'y' %}(or `conda`) {% endif %}into your environment.
+    python -m black --check {{ cookiecutter.project_slug }} tests
+    python -m isort --check {{ cookiecutter.project_slug }} tests
+    python -m blackdoc --check {{ cookiecutter.project_slug }} docs
+    python -m ruff {{ cookiecutter.project_slug }} tests
+    python -m flake8 {{ cookiecutter.project_slug }} tests
 
-Deployment
-----------
-
-A reminder for the **maintainers** on how to deploy. This section is only relevant when producing a new point release for the package.
-
-.. warning::
-
-    It is important to be aware that any changes to files found within the ``{{ cookiecutter.project_slug }}`` folder (with the exception of ``{{ cookiecutter.project_slug }}/__init__.py``) will trigger the ``bump-version.yml`` workflow. Be careful not to commit changes to files in this folder when preparing a new release.
-
-#. Create a new branch from `main` (e.g. `release-0.2.0`).
-#. Update the `CHANGES.rst` file to change the `Unreleased` section to the current date.
-#. Bump the version in your branch to the next version (e.g. `v0.1.0 -> v0.2.0`)::
-
-    $ bump-my-version bump minor # In most cases, we will be releasing a minor version
-    $ git push
-
-#. Create a pull request from your branch to `main`.
-#. Once the pull request is merged, create a new release on GitHub. On the main branch, run::
-
-    $ git tag v0.2.0
-    $ git push --tags
-
-   This will trigger a GitHub workflow to build the package and upload it to TestPyPI. At the same time, the GitHub workflow will create a draft release on GitHub. Assuming that the workflow passes, the final release can then be published on GitHub by finalizing the draft release.
-
-#. Once the release is published, the `publish-pypi.yml` workflow will go into an `awaiting approval` mode on Github Actions. Only authorized users may approve this workflow (notifications will be sent) to trigger the upload to PyPI.
-
-.. warning::
-
-    Uploads to PyPI can **never** be overwritten. If you make a mistake, you will need to bump the version and re-release the package. If the package uploaded to PyPI is broken, you should modify the GitHub release to mark the package as broken, as well as yank the package (mark the version  "broken") on PyPI.
-
-Packaging
----------
-
-When a new version has been minted (features have been successfully integrated test coverage and stability is adequate), maintainers should update the pip-installable package (wheel and source release) on PyPI as well as the binary on conda-forge.
-
-The simple approach
-~~~~~~~~~~~~~~~~~~~
-
-The simplest approach to packaging for general support (pip wheels) requires that ``flit`` be installed::
-
-    $ python -m pip install flit
-
-From the command line on your Linux distribution, simply run the following from the clone's main dev branch::
-
-    # To build the packages (sources and wheel)
-    $ python -m flit build
-
-    # To upload to PyPI
-    $ python -m flit publish dist/*
-
-The new version based off of the version checked out will now be available via `pip` (`$ pip install {{ cookiecutter.project_slug }}`).
-
-Releasing on conda-forge
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Initial Release
-^^^^^^^^^^^^^^^
-
-Before preparing an initial release on conda-forge, we *strongly* suggest consulting the following links:
- * https://conda-forge.org/docs/maintainer/adding_pkgs.html
- * https://github.com/conda-forge/staged-recipes
-
-In order to create a new conda build recipe, to be used when proposing packages to the conda-forge repository, we strongly suggest using the ``grayskull`` tool::
-
-    $ python -m pip install grayskull
-    $ grayskull pypi {{ cookiecutter.project_slug }}
-
-For more information on ``grayskull``, please see the following link: https://github.com/conda/grayskull
-
-Before updating the main conda-forge recipe, we echo the conda-forge documentation and *strongly* suggest performing the following checks:
- * Ensure that dependencies and dependency versions correspond with those of the tagged version, with open or pinned versions for the `host` requirements.
- * If possible, configure tests within the conda-forge build CI (e.g. `imports: {{ cookiecutter.project_slug }}`, `commands: pytest {{ cookiecutter.project_slug }}`).
-
-Subsequent releases
-^^^^^^^^^^^^^^^^^^^
-
-If the conda-forge feedstock recipe is built from PyPI, then when a new release is published on PyPI, `regro-cf-autotick-bot` will open Pull Requests automatically on the conda-forge feedstock. It is up to the conda-forge feedstock maintainers to verify that the package is building properly before merging the Pull Request to the main branch.
-
-Building sources for wide support with `manylinux` image
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-.. warning::
-    This section is for building source files that link to or provide links to C/C++ dependencies.
-    It is not necessary to perform the following when building pure Python packages.
-
-In order to do ensure best compatibility across architectures, we suggest building wheels using the `PyPA`'s `manylinux`
-docker images (at time of writing, we endorse using `manylinux_2_24_x86_64`).
-
-With `docker` installed and running, begin by pulling the image::
-
-    $ sudo docker pull quay.io/pypa/manylinux_2_24_x86_64
-
-From the {{ cookiecutter.project_slug }} source folder we can enter into the docker container, providing access to the `{{ cookiecutter.project_slug }}` source files by linking them to the running image::
-
-    $ sudo docker run --rm -ti -v $(pwd):/{{ cookiecutter.project_slug }} -w /{{ cookiecutter.project_slug }} quay.io/pypa/manylinux_2_24_x86_64 bash
-
-Finally, to build the wheel, we run it against the provided Python3.9 binary::
-
-    $ /opt/python/cp39-cp39m/bin/python -m build --sdist --wheel
-
-This will then place two files in `{{ cookiecutter.project_slug }}/dist/` ("{{ cookiecutter.project_slug }}-1.2.3-py3-none-any.whl" and "{{ cookiecutter.project_slug }}-1.2.3.tar.gz").
-We can now leave our docker container (`$ exit`) and continue with uploading the files to PyPI::
-
-    $ twine upload dist/*
+To get ``black``, ``isort``, ``blackdoc``, ``ruff``, and ``flake8`` (with plugins ``flake8-alphabetize`` and ``flake8-rst-docstrings``) simply install them with `pip` {% if cookiecutter.use_conda == 'y' %}(or `conda`) {% endif %}into your environment.
 
 Code of Conduct
 ---------------
diff --git a/{{cookiecutter.project_slug}}/Makefile b/{{cookiecutter.project_slug}}/Makefile
index 471cf6d57..9a4fda43a 100644
--- a/{{cookiecutter.project_slug}}/Makefile
+++ b/{{cookiecutter.project_slug}}/Makefile
@@ -141,4 +141,5 @@ install: clean ## install the package to the active Python's site-packages
 	python -m pip install .
 
 dev: clean ## install the package to the active Python's site-packages
-	python -m pip install --editable .
+	python -m pip install --editable .[all]
+	pre-commit install
diff --git a/{{cookiecutter.project_slug}}/docs/changelog.rst b/{{cookiecutter.project_slug}}/docs/changelog.rst
new file mode 100644
index 000000000..565b0521d
--- /dev/null
+++ b/{{cookiecutter.project_slug}}/docs/changelog.rst
@@ -0,0 +1 @@
+.. include:: ../CHANGELOG.rst
diff --git a/{{cookiecutter.project_slug}}/docs/changes.rst b/{{cookiecutter.project_slug}}/docs/changes.rst
deleted file mode 100644
index d9e113ec6..000000000
--- a/{{cookiecutter.project_slug}}/docs/changes.rst
+++ /dev/null
@@ -1 +0,0 @@
-.. include:: ../CHANGES.rst
diff --git a/{{cookiecutter.project_slug}}/docs/index.rst b/{{cookiecutter.project_slug}}/docs/index.rst
index 172867453..cae46ceb8 100644
--- a/{{cookiecutter.project_slug}}/docs/index.rst
+++ b/{{cookiecutter.project_slug}}/docs/index.rst
@@ -11,6 +11,7 @@
    installation
    usage
    contributing
+   releasing
 {%- if cookiecutter.create_author_file == 'y' %}
    authors
 {%- endif %}
diff --git a/{{cookiecutter.project_slug}}/docs/releasing.rst b/{{cookiecutter.project_slug}}/docs/releasing.rst
new file mode 100644
index 000000000..7737aa879
--- /dev/null
+++ b/{{cookiecutter.project_slug}}/docs/releasing.rst
@@ -0,0 +1,126 @@
+=========
+Releasing
+=========
+
+Deployment
+----------
+
+A reminder for the **maintainers** on how to deploy. This section is only relevant when producing a new point release for the package.
+
+.. warning::
+
+    It is important to be aware that any changes to files found within the ``{{ cookiecutter.project_slug }}`` folder (with the exception of ``{{ cookiecutter.project_slug }}/__init__.py``) will trigger the ``bump-version.yml`` workflow. Be careful not to commit changes to files in this folder when preparing a new release.
+
+#. Create a new branch from `main` (e.g. `release-0.2.0`).
+#. Update the `CHANGES.rst` file to change the `Unreleased` section to the current date.
+#. Bump the version in your branch to the next version (e.g. `v0.1.0 -> v0.2.0`)::
+
+   .. code-block:: console
+
+    bump-my-version bump minor # In most cases, we will be releasing a minor version
+    git push
+
+#. Create a pull request from your branch to `main`.
+#. Once the pull request is merged, create a new release on GitHub. On the main branch, run::
+
+   .. code-block:: console
+
+    git tag v0.2.0
+    git push --tags
+
+   This will trigger a GitHub workflow to build the package and upload it to TestPyPI. At the same time, the GitHub workflow will create a draft release on GitHub. Assuming that the workflow passes, the final release can then be published on GitHub by finalizing the draft release.
+
+#. Once the release is published, the `publish-pypi.yml` workflow will go into an `awaiting approval` mode on Github Actions. Only authorized users may approve this workflow (notifications will be sent) to trigger the upload to PyPI.
+
+.. warning::
+
+    Uploads to PyPI can **never** be overwritten. If you make a mistake, you will need to bump the version and re-release the package. If the package uploaded to PyPI is broken, you should modify the GitHub release to mark the package as broken, as well as yank the package (mark the version  "broken") on PyPI.
+
+Packaging
+---------
+
+When a new version has been minted (features have been successfully integrated test coverage and stability is adequate), maintainers should update the pip-installable package (wheel and source release) on PyPI as well as the binary on conda-forge.
+
+The simple approach
+~~~~~~~~~~~~~~~~~~~
+
+The simplest approach to packaging for general support (pip wheels) requires that ``flit`` be installed::
+
+   .. code-block:: console
+
+    python -m pip install flit
+
+From the command line on your Linux distribution, simply run the following from the clone's main dev branch::
+
+   .. code-block:: console
+
+    # To build the packages (sources and wheel)
+    make dist
+
+    # To upload to PyPI
+    make release
+
+The new version based off of the version checked out will now be available via `pip` (`pip install {{ cookiecutter.project_slug }}`).
+
+Releasing on conda-forge
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Initial Release
+^^^^^^^^^^^^^^^
+
+Before preparing an initial release on conda-forge, we *strongly* suggest consulting the following links:
+ * https://conda-forge.org/docs/maintainer/adding_pkgs.html
+ * https://github.com/conda-forge/staged-recipes
+
+In order to create a new conda build recipe, to be used when proposing packages to the conda-forge repository, we strongly suggest using the ``grayskull`` tool::
+
+   .. code-block:: console
+
+    python -m pip install grayskull
+    grayskull pypi {{ cookiecutter.project_slug }}
+
+For more information on ``grayskull``, please see the following link: https://github.com/conda/grayskull
+
+Before updating the main conda-forge recipe, we echo the conda-forge documentation and *strongly* suggest performing the following checks:
+ * Ensure that dependencies and dependency versions correspond with those of the tagged version, with open or pinned versions for the `host` requirements.
+ * If possible, configure tests within the conda-forge build CI (e.g. `imports: {{ cookiecutter.project_slug }}`, `commands: pytest {{ cookiecutter.project_slug }}`).
+
+Subsequent releases
+^^^^^^^^^^^^^^^^^^^
+
+If the conda-forge feedstock recipe is built from PyPI, then when a new release is published on PyPI, `regro-cf-autotick-bot` will open Pull Requests automatically on the conda-forge feedstock. It is up to the conda-forge feedstock maintainers to verify that the package is building properly before merging the Pull Request to the main branch.
+
+Building sources for wide support with `manylinux` image
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. warning::
+    This section is for building source files that link to or provide links to C/C++ dependencies.
+    It is not necessary to perform the following when building pure Python packages.
+
+In order to do ensure best compatibility across architectures, we suggest building wheels using the `PyPA`'s `manylinux`
+docker images (at time of writing, we endorse using `manylinux_2_24_x86_64`).
+
+With `docker` installed and running, begin by pulling the image::
+
+   .. code-block:: console
+
+    sudo docker pull quay.io/pypa/manylinux_2_24_x86_64
+
+From the {{ cookiecutter.project_slug }} source folder we can enter into the docker container, providing access to the `{{ cookiecutter.project_slug }}` source files by linking them to the running image::
+
+   .. code-block:: console
+
+    sudo docker run --rm -ti -v $(pwd):/{{ cookiecutter.project_slug }} -w /{{ cookiecutter.project_slug }} quay.io/pypa/manylinux_2_24_x86_64 bash
+
+Finally, to build the wheel, we run it against the provided Python3.9 binary::
+
+   .. code-block:: console
+
+    /opt/python/cp39-cp39m/bin/python -m build --sdist --wheel
+
+This will then place two files in `{{ cookiecutter.project_slug }}/dist/` ("{{ cookiecutter.project_slug }}-1.2.3-py3-none-any.whl" and "{{ cookiecutter.project_slug }}-1.2.3.tar.gz").
+We can now leave our docker container (`exit`) and continue with uploading the files to PyPI::
+
+   .. code-block:: console
+
+    python -m twine upload dist/*
diff --git a/{{cookiecutter.project_slug}}/pyproject.toml b/{{cookiecutter.project_slug}}/pyproject.toml
index 44880b318..22b6cdd89 100644
--- a/{{cookiecutter.project_slug}}/pyproject.toml
+++ b/{{cookiecutter.project_slug}}/pyproject.toml
@@ -91,6 +91,9 @@ docs = [
   "ipykernel",
   "jupyter_client"
 ]
+all = ["{{ cookiecutter.project_slug }}[dev]", "{{ cookiecutter.project_slug }}[docs]"]
+{%- else %}
+all = ["{{ cookiecutter.project_slug }}[dev]"]
 {%- endif %}
 {%- if cookiecutter.command_line_interface != "No command-line interface" %}
 
@@ -125,7 +128,7 @@ commit = true
 commit_args = "--no-verify"
 tag = false
 tag_name = "v{new_version}"
-allow_dirty = false
+allow_dirty = true
 parse = "(?P<major>\\d+)\\.(?P<minor>\\d+)\\.(?P<patch>\\d+)(\\-(?P<release>[a-z]+)(\\.(?P<build>\\d+)))?"
 serialize = [
   "{major}.{minor}.{patch}-{release}.{build}",
@@ -133,7 +136,7 @@ serialize = [
 ]
 
 [[tool.bumpversion.files]]
-filename = "{{ cookiecutter.project_slug }}/__init__.py"
+filename = "src/{{ cookiecutter.project_slug }}/__init__.py"
 search = "__version__ = \"{current_version}\""
 replace = "__version__ = \"{new_version}\""