[CHG] Updated doc for repository workflow

emencia · Aug 30, 2024 · 298f299 · 298f299
1 parent a3ecc34
commit 298f299
Show file tree

Hide file tree

Showing 4 changed files with 56 additions and 5 deletions.
diff --git a/CHANGELOG.rst b/CHANGELOG.rst
@@ -8,6 +8,10 @@ Version 1.4.0 - Unreleased
 
 * Added new plugin *Accordion*;
 * Disabled annoying Carousel autoplay in Slider template for sandbox;
+* Relaxed versions for requirements ``furo`` and ``sphinx-copybutton``;
+* Restricted Django requirement version to ``<5.1``, since DjangoCMS 3 is not
+  compatible with Django>=5.1 and for now this application is not yet planned to
+  support DjangoCMS 4;
 
 
 Version 1.3.2 - 2024/07/12

diff --git a/docs/development.rst b/docs/development.rst
@@ -47,10 +47,10 @@ To reach the administration you may need a super user: ::
     make superuser
 
 
-Unittests
----------
+Application tests
+-----------------
 
-Unittests are made to works on `Pytest`_, a shortcut in Makefile is available
+Tests are developed with `Pytest`_, a shortcut in Makefile is available
 to start them on your current development install: ::
 
     make test
@@ -93,6 +93,52 @@ Note that you need to build the documentation at least once before using
 ``livedocs``.
 
 
+Repository workflow
+-------------------
+
+Branch ``master`` is always the last released state. You never develop directly on it
+and only merge release once validated and released.
+
+All of your work need to start from a branch aligned on branch ``development`` which
+is where we merge validated work for on going version until released.
+
+Once release is done and merged in master, a new branch dedicated to the version need
+to be also created, like for the ``2.33.0`` branch you will create also a ``v2.33.0``
+branch. The version branches are never to be updated, they are only for version
+history.
+
+A contributor would start like this: ::
+
+    git clone REPOSITORY
+    git checkout development origin/development
+    git checkout -b my_new_feature
+    # ..Then implement your feature..
+    git commit -a -m "[NEW] Added new feature X"
+    git push origin my_new_feature
+
+At this point contributor need to open a pull request for its feature branch.
+
+Finally a project maintainer would pull the new branch and continue for releasing: ::
+
+    # Merge validated new feature branch into development
+    git checkout development
+    git merge my_new_feature
+    # ..Bump version and update Changelog
+    git commit -a -m "[NEW] (vX.x.x) Release"
+    git push origin development
+    # Finally merge new release into master
+    git checkout master
+    git merge development
+    git tag -a X.x.x COMMIT-HASH
+    git push --tags origin master
+    # Create the version branch
+    git checkout -b vX.x.x
+    git push origin vX.x.x
+
+
+Where ``X.x.x`` is dummy sample of a new version.
+
+
 Releasing
 ---------
 

diff --git a/docs/references/index.rst b/docs/references/index.rst
@@ -7,11 +7,11 @@ References
 .. toctree::
    :maxdepth: 2
 
+   accordion.rst
    album.rst
    card.rst
    container.rst
    hero.rst
    slider.rst
    feature.rst
    contrib.rst
-   accordion.rst
diff --git a/setup.cfg b/setup.cfg
@@ -3,7 +3,7 @@
 ;;
 [metadata]
 name = cmsplugin-blocks
-version = 1.4.0-pre.3
+version = 1.4.0-pre.4
 description = A set of DjangoCMS plugins for structured contents in CMS pages
 long_description = file:README.rst
 long_description_content_type = text/x-rst
@@ -39,6 +39,7 @@ classifiers =
 [options]
 include_package_data = True
 install_requires =
+    django<5.1.0
     django-cms>=3.11.0,<4.0
     djangocms-text-ckeditor>=5.0.1
     django-smart-media>=0.3.0