github.com/greenboxal/deis@v1.12.1/docs/roadmap/schedule.rst (about) 1 :title: Release Schedule 2 :description: When does Deis have major, minor, and patch releases? 3 4 .. _release_schedule: 5 6 Release Schedule 7 ================ 8 9 Some of the greatest assets of the Deis project are velocity and agility. 10 Deis changed rapidly and with relative ease during initial development. 11 12 Deis now harnesses those strengths into powering a regular, public release 13 cadence. From v1.0.0 onward, the Deis project will release a minor version each 14 month, with patch versions as needed. The project will use GitHub milestones to 15 communicate the content and timing of major and minor releases. 16 17 Deis releases are not feature-based, in that dates are not linked to specific 18 features. If a feature is merged before the release date, it is included in the 19 next minor or major release. 20 21 The master ``git`` branch of Deis always works. Only changes considered ready to 22 be released publicly are merged, and releases are made from master. 23 24 Semantic Versioning 25 ------------------- 26 27 Deis releases comply with `semantic versioning`_, with the "public API" broadly 28 defined as: 29 30 - the REST API for *deis-controller* 31 - etcd keys and values that are publicly documented 32 - ``deis`` and ``deisctl`` commands and options 33 - essential ``Makefile`` targets 34 - provider scripts under ``contrib/`` 35 36 Users of Deis can be confident that upgrading to a patch or to a minor release 37 will not change the behavior of these items in a backward-incompatible way. 38 39 Release Criteria 40 ---------------- 41 42 For any Deis release to be made publicly available, it must meet at least 43 these criteria: 44 45 - Passes all tests on the supported, load-balancing cloud providers 46 - Has no new regressions in behavior that are not considered trivial 47 48 Patch Releases 49 -------------- 50 51 A patch release of Deis includes backwards-compatible bug fixes. Upgrading to 52 this version is safe and can be done in-place. 53 54 Backwards-compatible bug fixes to Deis are merged into the master branch at any 55 time after they have :ref:`two approval comments <merge_approval>`. 56 57 Patch releases are created as often as needed, based on the priority of one or 58 more bug fixes that have been merged. If time or severity is crucial, an 59 individual maintainer can create a patch release without consensus from others. 60 Patch releases are created from a previous release by cherry-picking specific 61 bug fixes from the master branch, then applying and pushing the new release tag. 62 63 64 Minor Releases 65 -------------- 66 67 A minor release of Deis introduces functionality in a backward-compatible 68 manner. Upgrading to this version is safe and can be done in-place. 69 70 Backwards-compatible functionality changes to Deis are merged into the master 71 branch after they have :ref:`two approval comments <merge_approval>`, and after 72 the PR has been assigned to a milestone tracking the minor release. 73 74 It is preferable to merge several backwards-compatible functionality changes for 75 a single minor release. 76 77 The Deis project will use GitHub milestones to communicate the content and 78 timing of planned minor releases. Currently project maintainers meet each week 79 on Thursday afternoon to assign pull requests to milestones. 80 81 The Deis project will release a minor version of the platform on the first 82 Tuesday of each month. The target day may be shifted to accomodate holidays or 83 unusual circumstances. If project maintainers agree, an additional minor release 84 may occur between planned releases. Code freeze and :ref:`further acceptance 85 tests <features_to_be_tested>` begin on the Thursday before a targeted release. 86 87 A minor release may be superceded by a major release. 88 89 90 Major Releases 91 -------------- 92 93 A major release of Deis introduces incompatible API changes. Upgrading to this 94 version may involve a backup and restore process. Custom integrations with Deis 95 may need to be updated. 96 97 Incompatible changes to Deis are merged into the master branch deliberately, by 98 agreement among maintainers. In addition to 99 :ref:`two approval comments <merge_approval>`, the pull request must be assigned 100 to a planning milestone for that release, at which point it can be merged when 101 release activities and testing begin. 102 103 The Deis project will use GitHub milestones to communicate the content and 104 timing of planned major releases. 105 106 107 .. _`semantic versioning`: http://semver.org/spec/v2.0.0.html