Skip to content
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.

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

Introduce Docker versioning #200

Open
nupplaphil opened this issue Feb 17, 2022 · 3 comments
Open

Introduce Docker versioning #200

nupplaphil opened this issue Feb 17, 2022 · 3 comments
Labels
Enhancement New feature or request

Comments

@nupplaphil
Copy link
Collaborator

[...} New development, quick wins shouldn't be applied to stable version directly. Maybe stable version shouldn't be published from mainstream but from a tag?

You are doing a great work but it is really frustrating having an instance which could stop working at any time when my server pulls again the stable image.

Originally posted by @valvin1 in #196 (comment)

@nupplaphil nupplaphil added the Enhancement New feature or request label Feb 17, 2022
@nupplaphil
Copy link
Collaborator Author

nupplaphil commented Feb 17, 2022

I'm with you @valvin1 , I try to have a look how to achieve it.

The major point which gives me headache is that we need to introduce a different versioning concept as the Friendica upstream branch. That will lead to a complex versioning matrix:

Stable Docker images:

  • upstream: stable, docker: stable
  • upstream: dev, docker: stable
  • upstream: rc, docker: stable

Staging Docker images:

  • upstream: stable, docker: staging
  • upstream: dev, docker: staging
  • upstream: rc, docker: staging

But at https://github.com/docker-library/official-images/ , we would have to tag each image unique, so like friendica:stable-stable or friendica:staging-stable or friendica:stable-dev. I'm not sure if it's understandable for Docker image users, which version causes which state :)

Another idea would be to have to different repositories:

  • friendica for the stable (official) images
  • friendica/docker for the staging (early adopter) images

I think the second would be better understandable, but we would have to maintain two repositories. Another disadvantage is the missing quality-gate of the official docker-maintainer, who are giving sometimes a lot of feedback or sometimes request changes, would be a (late) loopback into the staging branch.

@valvin1
Copy link
Contributor

valvin1 commented Feb 18, 2022

hi,

thank you for investigating this :)

isn't possible without changing the actual worklow to push to docker registry only dev version / rc ? If I've understood PR done on their repository it is an association of a tag and a specific commit of this repository? maybe you could choose to send a new commit only for dev version (or a specific version when required).

@nupplaphil
Copy link
Collaborator Author

Oh. That's the far easiest possibility! Thanks :D I'll will adhere it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants