<commit_before>.. _release_process:

Release process
===============

These instructions follow the hypothetical release of Kolibri version '0.3.0'.

In this case, the repo would currently have a ``develop`` branch and a number of pre-existing release branches, the most recent being ``release-v0.2.x`` with potentially multiple tags for patch releases, e.g. ``v0.2.0`` and ``v0.2.1``.

Patch releases (e.g. '0.3.1') follow the same process outlined below, except that development occurs exclusively on an existing release branch (e.g. ``release-v0.2.x``). Patch releases generally do not have new user-facing strings, so translation- and font-related steps can be skipped


Create alpha releases
---------------------

For the majority of development on a new release, PRs will target the ``develop`` branch. Tag alpha releases as desired using Github's `Releases <https://github.com/learningequality/kolibri/releases>`__ functionality, which both adds a tag to the git repo and creates a placeholder on the Github site with built distributions.

Make sure to target ``develop``, use the standard tag naming convention (e.g. ``v0.3.0-alpha1``), and mark it has a "pre-release".

These alphas can be used for preliminary testing as major, unstable updates are introduced.

When a new alpha is published, *delete any older alphas* using Github's 'delete release' functionality. This will *not* delete the git tag.

It's common that changes have been made in the previous release that need to be propagated to the current release. For an upcoming 0.3.0 release, we would need to merge ``release-v0.2.x`` into ``develop``.

During the alpha phase is all the period when we should update our Python and Javascript dependencies. In general we should avoid updating dependencies in release branches.


String freeze and translation
-----------------------------

Once we are close to stabilizing the UI, we should schedule a string freeze. This date is the time after which no user-facing text in the application can be changed, because after string freeze we will begin getting quotes from translators and initiating the translation process.

Each minor release (``N.N.*``) is maintained in a CrowdIn Version Branch, following the existing naming scheme ``release-vN.N.x``. The branch is automatically created when running the first ``make i18n-upload`` command. CrowdIn will automatically reuse previously translated strings in new branches.

On the string freeze date, the strings for the upcoming release should be uploaded to crowdin as described in :ref:`crowdin`. You can run ``make i18n-stats branch=<release-vN.N.x>`` to get figures on the translation work. Send the stats to the i18n team, whom can use them for communication with translators to measure the translation efforts needed.

Strings from the Perseus plugin should also be revisited. They are maintained in the repo `learningequality/kolibri-exercise-perseus-plugin <https://github.com/learningequality/kolibri-exercise-perseus-plugin>`__, but the source strings are generated and uploaded through the main ``kolibri`` project. The translated files from CrowdIn such as ``exercise_perseus_render_module-messages.json`` are downloaded through the ``kolibri-exercise-perseus-plugin`` project. For instructions, see :ref:`crowdin`.

Before the translation start date, provide time to do one final review of all user-facing strings. This can be done e.g. in the course of doing a preliminary translation into Spanish.

When the user-facing strings have been signed off, the i18n team should notify translators that translation can begin.


Pin internal dependencies
-------------------------

Make sure all our internal dependencies are pointing at the correct, published versions. Specifically check:<commit_msg>Update file name for perseus JSON translations<commit_after>.. _release_process:

Release process
===============

These instructions follow the hypothetical release of Kolibri version '0.3.0'.

In this case, the repo would currently have a ``develop`` branch and a number of pre-existing release branches, the most recent being ``release-v0.2.x`` with potentially multiple tags for patch releases, e.g. ``v0.2.0`` and ``v0.2.1``.

Patch releases (e.g. '0.3.1') follow the same process outlined below, except that development occurs exclusively on an existing release branch (e.g. ``release-v0.2.x``). Patch releases generally do not have new user-facing strings, so translation- and font-related steps can be skipped


Create alpha releases
---------------------

For the majority of development on a new release, PRs will target the ``develop`` branch. Tag alpha releases as desired using Github's `Releases <https://github.com/learningequality/kolibri/releases>`__ functionality, which both adds a tag to the git repo and creates a placeholder on the Github site with built distributions.

Make sure to target ``develop``, use the standard tag naming convention (e.g. ``v0.3.0-alpha1``), and mark it has a "pre-release".

These alphas can be used for preliminary testing as major, unstable updates are introduced.

When a new alpha is published, *delete any older alphas* using Github's 'delete release' functionality. This will *not* delete the git tag.

It's common that changes have been made in the previous release that need to be propagated to the current release. For an upcoming 0.3.0 release, we would need to merge ``release-v0.2.x`` into ``develop``.

During the alpha phase is all the period when we should update our Python and Javascript dependencies. In general we should avoid updating dependencies in release branches.


String freeze and translation
-----------------------------

Once we are close to stabilizing the UI, we should schedule a string freeze. This date is the time after which no user-facing text in the application can be changed, because after string freeze we will begin getting quotes from translators and initiating the translation process.

Each minor release (``N.N.*``) is maintained in a CrowdIn Version Branch, following the existing naming scheme ``release-vN.N.x``. The branch is automatically created when running the first ``make i18n-upload`` command. CrowdIn will automatically reuse previously translated strings in new branches.

On the string freeze date, the strings for the upcoming release should be uploaded to crowdin as described in :ref:`crowdin`. You can run ``make i18n-stats branch=<release-vN.N.x>`` to get figures on the translation work. Send the stats to the i18n team, whom can use them for communication with translators to measure the translation efforts needed.

Strings from the Perseus plugin should also be revisited. They are maintained in the repo `learningequality/kolibri-exercise-perseus-plugin <https://github.com/learningequality/kolibri-exercise-perseus-plugin>`__, but the source strings are generated and uploaded through the main ``kolibri`` project. The translated files from CrowdIn such as ``kolibri_exercise_perseus_plugin.exercise_perseus_render_module-messages.json`` are downloaded through the ``kolibri-exercise-perseus-plugin`` project. For instructions, see :ref:`crowdin`.

Before the translation start date, provide time to do one final review of all user-facing strings. This can be done e.g. in the course of doing a preliminary translation into Spanish.

When the user-facing strings have been signed off, the i18n team should notify translators that translation can begin.


Pin internal dependencies
-------------------------

Make sure all our internal dependencies are pointing at the correct, published versions. Specifically check:
{'fraction_non_alphanumeric': 0.08787600157625115, 'fraction_numerical': 0.008669381321423881, 'mean_word_length': 4.309623430962343, 'pattern_counts': {'":': 0, '<': 9, '<?xml version=': 0, '>': 9, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4405946', 'n_tokens_mistral': 1913, 'n_tokens_neox': 1816, 'n_words': 1021}