readme: update the release policy - #186
Conversation
Until a recent discussion we have to update existing docker tag on Docker Hub if something is fixed in a Dockerfile. Now we reconsidered the process and decided to never change existing docker tags. The reason is simple: there should be a way to freeze an image to get rid of all possible negative impact due to a change. The discussion is raised by @tsafin. Thank you, Timur!
tsafin
left a comment
tsafin
left a comment
There was a problem hiding this comment.
In general I'm ok with current description of policy - clear enough and should improve things a lot.
|
|
||
| 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. |
There was a problem hiding this comment.
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
| ### 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. |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
I agree, it'll be more strict. I'll try to reword it as you proposed and will check how it looks.
| 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? |
There was a problem hiding this comment.
Security update release should be announced using same channels as usual release (i.e. twitter, site, telegram, mailing lists).
There was a problem hiding this comment.
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)orx.y.z-r1docker tag. So what about announcements in those cases?- If we'll publish the new
x.y.(z+1)release: just notify users about it as usual. - If we'll just fix the problem in
x.y.z.n: notify users about the security problem and versions where it is resolved (tarantoolx.y.z.n, the new docker tagx.y.z-r1).
- If we'll publish the new
- 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.
|
I'll get back when the time will permit. Sorry that I didn't fix comments at time. |
3 participants
Until a recent discussion we have to update existing docker tag on
Docker Hub if something is fixed in a Dockerfile. Now we reconsidered
the process and decided to never change existing docker tags.
The reason is simple: there should be a way to freeze an image to get
rid of all possible negative impact due to a change.
The discussion is raised by @tsafin. Thank you, Timur!