Skip to content

Release process

Jump to bottom
Dmitry Degtyarev edited this page Jun 23, 2022 · 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. Create a release branch from main branch. Name the branch release/x-y-0-test.
  3. Switch back to main branch and bump the minor version in spec file.

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. Final diff of the merge should be like this:
    • spec file should contain updated version from master
    • changelog in spec file should not contain the auto-generated entry (and comment) from master
    • changelog in spec file should contain all of the changelog entries from sisyphus
    • CHANGELOG.txt should contain changelog entry for the new version AND any entries for patches that aren't present in master but are in sisyphus (in correct order)
    • See merge commit for previous release->sisyphus merge for an example (but note that release procedures change so older merges may be outdated)
  7. Run add_changelog .gear/admc.spec
  8. Write a changelog entry in spec file. Follow this format: - x.y.z (See CHANGELOG.txt for details).
  9. Run gear-commit .gear/admc.spec
  10. Run gear-create-tag to create a tag for the new version.
  11. Push sisyphus branch and the tag back to git.alt.
  12. 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 install admc. (If you get an error about package lists, then check the log for the task and make sure that it complete successfully).
  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 #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 and also mention the subtask number.
  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. Delete tag you have previously created from local and remote sisyphus branches.
  4. 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.
  5. Update CHANGELOG.txt, if needed.
  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 <p9 task id> --commit -m "update"
ssh girar task run <p10 task id> --commit -m "update"
ssh girar task run <sisyphus task id> --commit -m "update"
  1. Run ssh girar task ls to confirm that status is correct. You should see this:
<p9 task id> POSTPONED #2 p9 admc.git=x.y.z-alt1
<p10 task id> POSTPONED #2 p10 admc.git=x.y.z-alt1
<sisyphus task id> BUILDING #1 [locked] sisyphus admc.git=x.y.z-alt1
  1. When testing is done, you can rename the release branch to release/x.y.0-stable.

Create patch releases

Sometimes you need to make a patch to a released version to fix an important bug. In this case you should increment the minor (x.y.Z) 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.

Changelog

Changelog is a bit weird and needs some upkeep. Changelog in release branches will contain changes from minor versions because they get merged in when release branches are merged into sisyphus branch. Changelog on upstream needs to be manually updated with changelogs from minor versions. Try to do that before releasing the next major version.

Clone this wiki locally