majic-ansible-roles Changeset

@@ -23,9 +23,9 @@ Versioning schema

  change. I.e. anything that depends on *Majic Ansible Roles* may need to make

  changes in order to keep working correctly.

- Minor number is bumped when new features or changes are made without breaking

  backwards compatibility. I.e. if you were you using vrersion ``1.2.3``, you

  should be safe to upgrade to version ``1.3.0`` without making any changes to

  whatever is using *Majic Ansible Roles*.

  backwards compatibility. I.e. if you were using version ``1.2.3``, you should

  be safe to upgrade to version ``1.3.0`` without making any changes to whatever

  is using *Majic Ansible Roles*.

- Patch number is bumped when making purely bug-fix backwards compatible

  changes. Patch releases are generally more likely to remain stable simply due

  to limited scope of changes (new features can sometimes introduce unexpected

@@ -34,18 +34,20 @@ Versioning schema

  more scarce, and I might opt for going for minor release instead to reduce

  amount of work needed (backporting and releasing).

In addition to versioning schema used for release, *Majic Ansible Roles* employs

a specific nomenclature for naming the branches:

In addition to versioning schema, *Majic Ansible Roles* employs a specific

nomenclature for naming the branches:

- All new development and bug-fixing first happens on the master branch.

- An implementation branch has its name set to the associated issue,

  lower-cased. For example, if the issuer number is ``MAR-43``, the

  implementation branch will be named ``mar-43``. Normally these branches are

  only local, but if necessary they can be pushed to the repository.

- Mainteance branches are named after the ``MAJOR`` and ``MINOR`` number of the

  version. For example, if a new release is made with version ``1.2.0``, the

  corresponding branch that is created for maintenance will be named ``1.2``

  (notice the absence of ``.0`` at the end).

- All new development and bug-fixing uses master branch as the base.

- Features and bug-fixes are implemented in a local branch based on the master

  branch. Local branches are named after the lower-cased issue number. For

  example, if the issuer number is ``MAR-43``, the implementation branch will be

  named ``mar-43``. Normally these branches are only local, but if necessary

  they can be pushed to the repository (for sharing etc).

- Patch releases are based off the maintenance branches. Mainteance branches are

  named after the ``MAJOR`` and ``MINOR`` number of the version. For example, if

  a new release is made with version ``1.2.0``, the corresponding branch that is

  created for maintenance will be named ``1.2`` (notice the absence of ``.0`` at

  the end).

Backporting fixes

@@ -64,13 +66,15 @@ should be applied to maintenance branch as well, procedure is as follows:

2. Create a copy of the bug report, modifying the issue title to include phrase

   ``(backport to MAJOR.MINOR)`` at the end, with ``MAJOR`` and ``MINOR``

   replaced with correct versioning information for the maintenance branch.

   replaced with correct versioning information for the maintenance

   branch. Make sure to set correct target version (patch release).

3. Resolve the bug for next major/minor release.

4. Reslove the bug in maintenace branch by backporting (cherry-picking if

   possible) the fix into maintenace branch. Make sure to resign the commit

   since cherry-picking invalidates signature.

   possible) the fix into maintenace branch. Make sure to resign (cherry-picking

   invalidates signature) and reword (to reference the backport issue) the

   commit.

Releasing new minor/major version

@@ -116,6 +120,9 @@ When releasing a new minor/major version, procedure is as follows:

9. Add release notes to file ``docs/releasenotes.rst``. Release notes template

   should be as follows::

     VERSION

     -------

     GENERAL DESCRIPTION

     New roles:

@@ -237,11 +244,15 @@ When releasing a new minor/major version, procedure is as follows:

      git checkout master

30. Mark issues as resolved in the issue tracker.

30. Delete the local branch::

      git branch -d "${ISSUE,,}"

31. Mark issue as resolved in the issue tracker.

31. Release the version via release center in the issue tracker.

32. Release the version via release center in the issue tracker.

32. Archive all other releases.

33. Archive all other releases.

Releasing new patch version

@@ -289,6 +300,9 @@ When releasing a new patch release, procedure is as follows:

10. Add release notes to file ``docs/releasenotes.rst``. Release notes template

    should be as follows::

      VERSION

      -------

      GENERAL DESCRIPTION

      Bug-fixes:

@@ -353,7 +367,7 @@ When releasing a new patch release, procedure is as follows:

21. Merge changes back into the maintenance branch::

      git checkout "${NEW_VERSION%.*}

      git checkout "${NEW_VERSION%.*}"

      git merge "${ISSUE,,}"

22. Push the tag and changes to mainteance branch::

@@ -361,13 +375,17 @@ When releasing a new patch release, procedure is as follows:

      git push

      git push origin "${NEW_VERSION}"

23. Switch back to the master branch::

23. Delete the local branch::

      git branch -d "${ISSUE,,}"

24. Switch back to the master branch::

      git checkout master

24. Mark issues as resolved in the issue tracker.

25. Mark issue as resolved in the issue tracker.

25. Release the version via release center in the issue tracker.

26. Release the version via release center in the issue tracker.

26. Archive all old patch releases with the same major and minor number as new

27. Archive all old patch releases with the same major and minor number as new

    release version.