Release process

This is an instruction on how to release ADMC on ALT Linux. This process is mostly similar to trunk based development with some extra steps necessary to deal with ALT repository branches and testing. To perform these steps to completion you need ALT maintainer rights, which requires "join": https://www.altlinux.org/Join.

Create the release branch

1. Let's say that version x.y.0 is ready for release.
2. Add a section for the new version to CHANGELOG.txt. Remember to add changelog sections from patch versions of previous versions. For example, if previous version had a patch that fixed some bug, the changelog for new major version should also indicate that the bug is fixed.
3. Create a release branch from main branch. Name the branch release/x-y-0-test.
4. Switch back to main branch and bump the version. "Bumping" means changing the version in .gear/admc.spec to x.y+1.0.
5. On release branch, turn off the "development" flag in the spec file and commit. Change line %define _development 1 to %define _development 0. This changes how package name is constructed from including latest hash to including latest version. Name the commit for this change x.y.0.

Create sisyphus branch

For the next steps, you will need to have access to git.alt. See altlinux wiki for info on how to get it.

1. Setup your own repo clone by running ssh git.alt clone git://git.altlinux.org/gears/a/admc.git admc.
2. If you already have a repo clone, make sure it is up to date by pulling from the gears repo.
3. Add git.alt remote locally: git remote add alt gitery.alt:packages/admc (replace gitery.alt with your hostname for gitery in ssh config). Note that normal "git://" style url won't work.
4. Pull sisyphus branch from your clone.
5. Merge the release branch into sisyphus branch.
6. Tag head of the sisyphus branch by running gear-create-tag.
7. Push sisyphus branch and the tag back to git.alt.

Test the release yourself

Depending on the volume of changes or your laziness you may skip some of this.

1. Build a test task: ssh girar build packages/admc.git x.y.0-alt1 --test-only -b p10 -m "update". Build another test task for p9 if you're using p9.
2. Install test-only task locally: sudo apt-repo add <task-id> && sudo apt-get admc.
3. Run admc package and make sure it at least starts up.
4. Install tests sudo apt-get admc-test and run all the tests.
5. You can also run these tests on vm's with different architectures.

Send the release to testers

This step is optional but highly recommended. Normally, releases get sent to testers automatically when they are pushed to sisyphus/p10/p9. The problem with that is that testing happens only on the p10/p9 step, so an untested release will be pushed to sisyphus. Then, if testers find any problems during p10/p9 testing, you'll have to make a new patch version just to pass testing. If you perform the steps below, the release will be tested before pushing to sisyphus.

1. Create a task on redmine manually for the test-only task you just made.
2. Open the task in the "p10 repository" section.
3. Name it task-id p10/your-username admc.git=x.y.0-alt1 try 1.
4. Set type to "Testing".
5. Assign task to "QA common user".
6. Add a webery link to the task in the description: http://webery.altlinux.org/task/task-id.
7. Add any other relevant info about changes to description.
8. Wait for task to get tested.

Updating test task

If during the previous section, testers found a problem, you will have to fix it and send the release for testing again.

1. Fix the problem.
2. Commit fix to main branch.
3. Cherry pick fix from main branch to release branch. If cherry picking is not possible because the main branch is too different from release branch, you may create separate fixes in main and release branches and deal with conflicts during merges later.
4. Update CHANGELOG.txt, if needed.
5. Delete tag you have previously created from local and remote sisyphus branches.
6. Repeat steps in "Create sisyphus branch" section, but use --force option when pushing.
7. Instead of creating a new task, you need to modify current one
8. Get info about current task: ssh girar task show <task-id>.
9. Find the # of the most recent subtask in the output, should be "x00".
10. Delete old subtask: ssh girar task delsub <task-id> <subtask-id>.
11. Create new subtask: ssh girar task add <task-id> repo packages/admc.git x.y.z-alt1.
12. Run task again: ssh girar task run <task-id> --test-only -m "update".
13. Update "try #" in task name.
14. Repeat until release passes testing.

Push release to sisyphus/p10/p9 repositories

1. Push to sisyphus: ssh girar build packages/package.git x.y.0-alt1 --commit -b "sisyphus" -m "update"
2. Create a dependent task that will push to p10 when sisyphus task is done:

• ssh girar task new p10
• ssh girar task add <p10 task id> repo packages/admc.git x.y.0-alt1
• ssh girar task deps <p10 task id> add <sisyphus task id>
• ssh girar task run <p10 task id> --commit -m "update"

3. Create a dependent task that will push to p9 when p10 task is done. See previous step.
4. Wait for testing to complete.
5. When testing is done, you can rename the release branch to release/x.y.0-stable.

Create patch releases

In case testers still miss a problem in preliminary testing and find it later, you will have to make a patch version. You should also make patch versions for fixes that you want to release before next main version.

1. Process is mostly similar to making a regular release.
2. Except that you branch from the previous release instead of from main branch.
3. For example, let's say a fix is contained in 1 commit. You put that commit into main branch.
4. Then branch from release/x.y.0-stable into release/x.y.1-test.
5. Cherry pick fix into patch branch.
6. Continue with regular release procedure.