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

Improve docker image versioning. #894

Open
hardwareadictos opened this issue Jun 23, 2023 · 5 comments
Open

Improve docker image versioning. #894

hardwareadictos opened this issue Jun 23, 2023 · 5 comments
Labels
enhancement New feature or request

Comments

@hardwareadictos
Copy link

Describe the enhancement you'd like
For example instead tagging images only as "latest" and "dev", doing v1, v1.1, v1.2 builds.

Describe why this will benefit the LibrePhotos
Would be useful also to prevent regresions on latest/dev tag.

Additional context
Would be nice for people (like me) who wants to control versioning and jump between versions instead always pulling latest on production environments and dev on testing ones.

@martijn-gr
Copy link

To my knowledge you have versioning for containers, although they do not come with a vMajor.Minor.Build numbering, but with a ${year}w${week} numbering,
Please have a look at the DockerHub https://hub.docker.com/r/reallibrephotos/librephotos/tags and you will understand what I mean.

@hardwareadictos
Copy link
Author

Yes, understood. But they seem not up to date with "latest" images:

image

Those are supposed to be "weekly builds" but are updated once per month. Would be nice to have an update per week like latest image.

@martijn-gr
Copy link

martijn-gr commented Jul 30, 2023

I am not sure where you got that these are weekly builds, sure the version ing suggests it, but as you can see that is clearly not the case.

Also remarkable that you seem to ignore the fact that latest and 2023w26.1 have the same digest signature.

There are no newer containers at this moment latest is 2023w26.1, only dev is newer.

I do agree that it would be useful to make the versioning between Docker hub containers and Github release tags equal.
In the end it doesn't make sense to release new containers with the same codebase just to produce a new weekly container.

@hardwareadictos
Copy link
Author

I am not sure where you got that these are weekly builds, sure the version ing suggests it, but as you can see that is clearly not the case.

Also remarkable that you seem to ignore the fact that latest and 2023w26.1 have the same digest signature.

There are no newer containers at this moment latest is 223w26.1, only dev is newer.

Well i assume that this w on "2023w26" references the "week". And what i say is that would be nice to have weekly builds, as dev updates every week would be nice to follow the same procedure on "latest tagged images", but i understand that this is up to the developers.

And yes. Didn't see the digests.

@martijn-gr
Copy link

And what i say is that would be nice to have weekly builds, as dev updates every week would be nice to follow the same procedure on "latest tagged images", but i understand that this is up to the developers.

And yes. Didn't see the digests.

It would be nice to do nightly builds based of the dev branch for those who want to check out the latest changes.
But given the current development cycle I do not know whether this is really useful. Functions might be more broken than in the more stable periodic release.

As there aren't that many developers a more streamlined release cycle with QA/pre release doesn't make sense to me.

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