PaddlePaddle Releasing Process
PaddlePaddle manages its branches using "git-flow branching model", and Semantic Versioning as it's version number semantics.
Each time we release a new PaddlePaddle version, we should follow the below steps:
- Fork a new branch from
- Push a new tag on the release branch, the tag name should be like
[version]rc.patch. The first tag should be
0.10.0rc1, and the second should be
0.10.0.rc2and so on.
- After that, we should do:
- Run all regression test on the Regression Test List (see PaddlePaddle TeamCity CI), to confirm
that this release has no major bugs.
* If regression test fails, we must fix those bugs and create a new
release/[version]branch from previous release branch.
python/setup.py.in, change the version number and change
- Publish PaddlePaddle release wheel packages to pypi (see below instructions for detail).
- Update the Docker images (see below instructions for detail).
- After above step, merge
release/[version]branch to master and push a tag on the master commit, then merge
- Update the Release Note.
- Do NOT merge commits from develop branch to release branches to keep the release branch contain features only for current release, so that we can test on that version.
- If we want to fix bugs on release branches, we must merge the fix to master, develop and release branch.
Publish Wheel Packages to pypi
- Use our CI tool to build all wheel packages needed to publish. As shown in the following picture, choose a build version, click "..." button on the right side of "Run" button, and switch to the second tab in the pop-up box, choose the current release branch and click "Run Build" button. You may repeat this step to start different versions of builds.
- After the build succeeds, download the outputs under "Artifacts" including capi,
- Since pypi.python.org follows PEP 513, before we
upload the package using
twine, we need to rename the package from
Start the upload:
cd build/python pip install twine twine upload dist/[package to upload]
NOTE: We use a special Docker image to build our releases to support more Linux distributions, you can download it from https://hub.docker.com/r/paddlepaddle/paddle_manylinux_devel/tags/, or build it using scripts under
- pypi does not allow overwrite the already uploaded version of wheel package, even if you delete the old version. you must change the version number before upload a new one.
Publish wheel Packages for MacOS
You need to build the binary wheel package for MacOS before publishing, to make sure that the package can be used by many versions of MacOS (10.11, 10.12, 10.13) and different python installs (python.org, homebrew, etc.), you must build the package exactly following below steps:
- install python from python.org downloads, and make sure it's currently in use in your system.
export MACOSX_DEPLOYMENT_TARGET=10.11, use
10.11is enough for recent versions.
git clone https://github.com/PaddlePaddle/Paddle.git && cd Paddle && mkdir build && cd build
cmake -DWITH_GPU=OFF -DWITH_MKL=OFF -DWITH_SYSTEM_BLAS=OFF .., make sure the output of
cmakecommand is using the correct python interpreter installed from python.org
pip install delocate
mkdir fixed_wheel && delocate-wheel -w fixed_wheel python/dist/*.whl
Then the whl under
fixed_wheel is ready to upload.
pip install paddlepaddle...whl
- find the
libpython.dylibthat are currently in use:
- for python.org package installs, do nothing.
- for other python installs, find the path of
export LD_LIBRARY_PATH=you path && DYLD_LIBRARY_PATH=your path
Publish Docker Images
Our CI tool will push latest images to DockerHub, so we only need to push a version tag like:
docker pull [image]:latest docker tag [image]:latest [image]:[version] docker push [image]:[version]
Tags that need to be updated are:
[version]: CPU only version image
[version]-openblas: openblas version image
[version]-gpu: GPU version（using CUDA 8.0 cudnn 5）
[version]-gpu-[cudaver]-[cudnnver]: tag for different cuda, cudnn versions
You can then checkout the latest pushed tags at https://hub.docker.com/r/paddlepaddle/paddle/tags/.
We use git-flow as our branching model, with some modifications:
masterbranch is the stable branch. Each version on the master branch is tested and guaranteed.
developbranch is for development. Each commit on develop branch has passed CI unit test, but no regression tests are run.
release/[version]branch is used to publish each release. Latest release version branches have bugfix only for that version, but no feature updates.
- Developer forks are not required to follow
branching model, all forks is like a feature branch.
- Advise: developer fork's develop branch is used to sync up with main repo's develop branch.
- Advise: developer use it's fork's develop branch to for new branch to start developing.
- Use that branch on developer's fork to create pull requests and start reviews.
- developer can push new commits to that branch when the pull request is open.
- Bug fixes are also started from developers forked repo. And, bug fixes branch can merge to
PaddlePaddle Regression Test List
All Chapters of PaddlePaddle Book
We need to guarantee that all the chapters of PaddlePaddle Book can run correctly. Including
paddle_trainer training) and V2 training and Fluid training.
|Linear Regression||Recognize Digits||Image Classification||Word2Vec||Personalized Recommendation||Sentiment Analysis||Semantic Role Labeling||Machine Translation|
|API.V2 + Docker + GPU|
|API.V2 + Docker + CPU|
|`paddle_trainer` + Docker + GPU|
|`paddle_trainer` + Docker + CPU|
|API.V2 + Ubuntu + GPU|
|API.V2 + Ubuntu + CPU|
|`paddle_trainer` + Ubuntu + GPU|
|`paddle_trainer` + Ubuntu + CPU|