1.. _development: 2 3================================================================================ 4Development of |Percona Server| 5================================================================================ 6 7|Percona Server| is an open source project to produce a distribution 8of the MySQL Server with improved performance, scalability and 9diagnostics. 10 11Submitting Changes 12================================================================================ 13 14We keep trunk in a constant state of stability to allow for a release at 15any time and to minimize wasted time by developers due to broken code. 16 17Overview 18-------------------------------------------------------------------------------- 19 20At Percona we use `Git <https://git-scm.com>`_ for source control, `GitHub 21<https://github.com/percona>`_ for code hosting, and `Jira 22<https://jira.percona.com>`_ for release management. 23 24We change our software to implement new features and/or to fix bugs. Refactoring 25could be classed either as a new feature or a bug depending on the scope of 26work. 27 28New features and bugs are targeted to specific releases. A 29release is part of a series. For example, 2.4 is a series in Percona 30XtraBackup and 2.4.15, 2.4.16 and 2.4.17 are releases in this series. 31 32Code is proposed for merging in the form of pull requests on GitHub. 33 34For |Percona Server|, we have several Git branches on which development occurs: 355.5, 5.6, 5.7, and 8.0. As |Percona Server| is not a traditional project, instead 36of being a set of patches against an existing product, these branches are not 37related. In other words, we do not merge from one release branch to another. To 38have your changes in several branches, you must propose branches to each release 39branch. 40 41Making a Change to a Project 42-------------------------------------------------------------------------------- 43 44In this case, we are going to use ``percona-xtrabackup`` as an example. The 45workflow is similar for |Percona Server|, but the patch will need to be modified 46in all release branches of |Percona Server|. 47 48* ``git branch https://github.com/percona/percona-xtrabackup/featureX`` (where 'featureX' is a 49 sensible name for the task at hand) 50* (developer makes changes in featureX, testing locally) 51* The Developer pushes to ``https://github.com/percona/username/percona-xtrabackup/featureX`` 52* The developer can submit a pull request to https://github.com/percona/percona-xtrabackup, 53* Code undergoes a review 54* Once code is accepted, it can be merged 55 56If the change also applies to a stable release (e.g. 2.4) then changes should be 57made on a branch of 2.4 and merged to a branch of trunk. In this case there 58should be two branches run through the param build and two merge proposals (one 59for the stable release and one with the changes merged to trunk). This prevents 60somebody else having to guess how to merge your changes. 61 62|Percona Server| 63-------------------------------------------------------------------------------- 64 65The same process for |Percona Server|, but we have several different branches 66(and merge requests). 67