| | 1 | = Committing Your Changes = |
| | 2 | |
| | 3 | Before continuing: |
| | 4 | * ensure you have [wiki:WorkingWithGithub set up your fork and remote] for the module you're working on. |
| | 5 | * ensure you have read [wiki:WorkingWithTheRepository], especially the part on native vs non-native packages, deatched HEADs, and branches. |
| | 6 | |
| | 7 | == Native Packages == |
| | 8 | |
| | 9 | For native packages, changes are broken into changes to the "upstream" code itself (on the `master` branch), or changes to the packaging (on the `debian` branch). For example, if [https://github.com/mit-athena/getcluster getcluster] throws a Python exception, and you fix that, that would be a change to the code itself. If, on the other hand, you're just updating a dependency in the `control` file, then that's a change to the packaging only. |
| | 10 | |
| | 11 | === Changing `master` === |
| | 12 | |
| | 13 | * Make your changes to the code to fix whatever bug you're fixing or add whatever feature you're adding. |
| | 14 | * Ensure that you update the software's version number as appropriate. Software is versioned in one of 3 places: |
| | 15 | * `configure.ac` -- in the `AC_INIT` macro |
| | 16 | * `setup.py` -- in the `version` keyword argument to the `setup()` function |
| | 17 | * `VERSION` -- a plain-text file at the top-level of the source tree containing a version number |
| | 18 | * Commit your changes, and push them to **your** remote. Submit a pull request as [wiki:WorkingWithGithub described here], and wait for code review, or decide that this is important enough that it doesn't need code review. |
| | 19 | |
| | 20 | * Tag your most recent commit with the version number (this MUST match the version number as described above). |
| | 21 | * `git tag -a 10.0.3 a4b5c6d7` |
| | 22 | * Push your master, and the tag to `origin` (`git+ssh://git.mit.edu/[...]`). |
| | 23 | * `git push origin master` |
| | 24 | * `git push origin 10.0.3` |
| | 25 | * '''Once you do this, the version is finalized. If you find a bug, you'll need to bump the version number and repeat this process. |
| | 26 | * Checkout the `debian` branch, and merge your changes into master, *ensuring you get a merge commit, not a fast-forward* |
| | 27 | * `git checkout debian` |
| | 28 | * `git merge --no-ff master` |
| | 29 | * Proceed to the next section to update the packaging. |
| | 30 | |
| | 31 | === Changing `debian` === |
| | 32 | |
| | 33 | * Make any changes to the packaging |
| | 34 | * Ensure you add a new Debian changelog entry. |
| | 35 | * The upstream component of the version **must** match the tag in `master`, and the distro-specific component should be `-0debathena1`, incrementing the last digit as necessary, if there are packaging-only changes. For example, using version `10.0.3` as above, the entry in `debian/changelog` should be `10.0.3-0debathena1`. |
| | 36 | * Commit your changes. |
| | 37 | **NOTE**: If the changes to packaging are more complicated than a new changelog entry (e.g. if you're changing maintainer scripts, or the `rules` file), push to **your** remote, and submit another pull request. |
| | 38 | * Push to `origin`: |
| | 39 | * `git push origin debian` |
