Skip to content

Release process

Jump to bottom
Dmitry Degtyarev edited this page Nov 22, 2021 · 22 revisions

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 release branch. Don't name it after the version because you might need to add more commits.

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.
  8. If you got "is not inherited" error during build in sisyphus, you may have done the above steps incorrectly. Make sure you're merging new changes on top of the currently up-to-date sisyphus branch.

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-repo update && sudo apt-get admc.
  3. Run admc package and make sure it at least starts up.
  4. Install tests sudo apt-get install 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. Here's the sequence of steps to build for all three repo's using a dependency chain of tasks:
ssh girar task new sisyphus
ssh girar task new p10
ssh girar task new p9
ssh girar task add <sisyphus task id> repo packages/admc.git x.y.0-alt1
ssh girar task add <p10 task id> repo packages/admc.git x.y.0-alt1
ssh girar task add <p9 task id> repo packages/admc.git x.y.0-alt1
ssh girar task deps <p10 task id> add <sisyphus task id>
ssh girar task deps <p9 task id> add <p10 task id>
ssh girar task run <sisyphus task id> --commit -m "update"
ssh girar task run <p10 task id> --commit -m "update"
ssh girar task run <p9 task id> --commit -m "update"
2. Run `ssh girar task ls` to confirm that status is correct. You should see this:

POSTPONED #2 p9 admc.git=x.y.z-alt1 POSTPONED #2 p10 admc.git=x.y.z-alt1 BUILDING #1 [locked] sisyphus admc.git=x.y.z-alt1

3. 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.
Clone this wiki locally