pandas-dev/pandas
1
0
Fork 0
mirror of https://github.com/pandas-dev/pandas.git synced 2026-05-30 01:03:43 +08:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity
Page: Backporting
Pages
(Tentative) rules for restructuring indexing code . A quick overview of pandas.util Adding new maintainers Backporting Benchmark Machine Building On Windows Building and uploading the official documentation Choosing Exceptions to Raise Code Style and Conventions Documenting new features and bug fixes Gana Git Workflows Google Summer of Code Home Indexing API Reference Maintainer Overview Merging Commits Pandas Development Meetings Pandas Sprint (July, 2018) Performance Testing Posting rendered documentation page change in github issues. Regenerating CONTRIBUTING.md Release Checklist Specialities Sphinx Nuances Testing Time Series Manipulation Using Git
Clone
2
Backporting
Joris Van den Bossche edited this page 2017-04-07 00:00:04 +02:00

Backporting example for 0.19.x.

Original Backporting issues is here

  • Everything is merged in master:
    • For an issue/PR: discuss if it should go into a bug fix release, and if so: tag it with the appropriate milestone (in this case: 0.19.1)
    • PR tagged with 0.19.1 still targets master, but is written as it is for 0.19.1 (whatsnew notice in the 0.19.1 file, mentioning this release number where needed)
    • PR is merged into master
  • Backport to 0.19.x branch:

    • Backport branch 0.19.x can be branched of master just before the point the first commit is added to master that should not be included in the bugfix release

    • The one resulting commit of the PR is backported to the 0.19.x branch using cherry-pick and fix conflicts when needed (in practice this was almost never needed for the 0.19.x releases). So I mainly did:

      git checkout 0.19.x
git cherry-pick ..commit-sha..

    • In practice, what I did was the following:

      • Go through the history of master (from where 0.19.x was branched to more recent), check for each commit whether it needs backporting (based on tag of connected PR, at once extra check this tagging was actually correct based), and if so copy sha and cherry-pick it.
      • I did this a couple times for a whole bunch at once, and you can just check the latest commit in the 0.19.x branch where you left off the previous time.

I also had a script that could automate this a little bit, but in practice it didn't give much value above using the cherry-pick (you could give the PR number instead of the commit sha). But in theory, we could write a script that gets all PRs, check that they were tagged with the specific release, and cherry-pick them in order, to automate this (supposing all changes went through PRs). But not sure this is worth the effort. What I used then is here: https://gist.github.com/jorisvandenbossche/e97c22f7176180a5548f767e520586bb#file-backport-pr-py-L113-L126

For Developers

For maintainers