Skip to content

readme: update the release policy #186

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 18, 2020
Merged

readme: update the release policy #186

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 34 additions & 32 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -367,44 +367,46 @@ Special builds:
| 1.x-centos7 | dockerfile/centos_7 |
| 2.x-centos7 | dockerfile/centos_7 |

## How to push changes (for maintainers)
## Release policy

When the change is about specific tarantool version or versions
range, update all relevant fixed versions & rolling versions
according to the pipelines listed above.
All images are pushed to [Docker Hub](docker_hub_tags).

When the change is about the environment at all, all versions
need to be updated.
Fixed version tags (`x.y.z`) are frozen: we never update them.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we assume there will be hot updates with some suffixes (or numbers?) after the 3rd number, then we should extend definition of fixed tag


Add a new release (say, x.y.z). Create / update rolling
versions x and x.y in master, create fixed version x.y.z.
Rolling versions are updated to the last fixed version tags:

A maintainer is responsible to check updated images.
- `x.y` == `x.y.<last-z>` (`==` means 'points to the same image')
- `1` == `1.<last-y>.<last-z>`
- `2` == `2.<last-y>.<last-z>`
- `latest` == `2`

[1]: https://tarantool.io/en/doc/1.9/dev_guide/release_management/#how-to-make-a-minor-release
Special builds (CentOS) are updated with the same policy as rolling versions:

## How to push images (for maintainers)
Gitlab-CI jobs after the images builds push it to its local
images repository in the format:
registry.gitlab.com/tarantool/docker:<tag>
To push collected images into the 'docker.io' repository with
the following format:
docker.io/tarantool/tarantool:<tag>
the following scripts can be used:
- `1.x-centos7` image offers a last `1.<last-y>.<last-z>` release
- `2.x-centos7` image offers a last `2.<last-y>.<last-z>` release

```bash
echo List of available tags: \
`grep " VER: " .gitlab-ci.yml | awk -F"'" '{print $2}'`
```
[docker_hub_tags]: https://hub.docker.com/r/tarantool/tarantool/tags

```bash
for tag in <list of tags> ; do \
echo "============= $tag ==============" ; \
docker pull registry.gitlab.com/tarantool/docker:$tag && \
docker tag registry.gitlab.com/tarantool/docker:$tag \
tarantool/tarantool:$tag && \
docker push tarantool/tarantool:$tag ; \
echo "$tag push resulted with: $?" ; \
done
```
### Exceptional cases

As an exception we can deliver an important update for the existing tarantool
release within `x.y.z-r1`, `x.y.z-r2`, ... tags.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Uh, I see you've mentioned them here. But still believe it worth to mention that updates are the same kind of fixed tags. But, well, I'm not insisting (because current description is clear enough)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, it'll be more strict. I'll try to reword it as you proposed and will check how it looks.


When `x.y.z-r<N>` is released, the corresponding rolling releases (`x.y`, `x`
and `latest` if `x` == 2) should be updated to point to the same image.

There is no strict policy, which updates should be considered important. Let's
decide on demand and define the policy later.

TBD: How to notify users about the exceptional updates?
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Security update release should be announced using same channels as usual release (i.e. twitter, site, telegram, mailing lists).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two possible cases:

  • Security update of tarantool. It is unclear whether we'll publish a new release in the case. But anyway, we either publish x.y.(z+1) or x.y.z-r1 docker tag. So what about announcements in those cases?
    1. If we'll publish the new x.y.(z+1) release: just notify users about it as usual.
    2. If we'll just fix the problem in x.y.z.n: notify users about the security problem and versions where it is resolved (tarantool x.y.z.n, the new docker tag x.y.z-r1).
  • Security update of a docker image (dependencies and so). We'll notify users about the docker image update.

Okay, now I have a clear picture in the mind. I'll update the PR with something like 'usual announcement channels' and will describe when an update requires a separate announcement and when it should be includes into some more general one.


## How to push an image (for maintainers)

Example:

```console
$ export TAG=2
$ export OS=alpine DIST=3.9 VER=2.x # double check the values!
$ PORT=5200 make -f .gitlab.mk build
$ docker push tarantool/tarantool:${TAG}
```