LibrePhotos / librephotos

A self-hosted open source photo management service. This is the repository of the backend.
MIT License
7.01k stars 309 forks source link

Improve docker image versioning. #894

Open hardwareadictos opened 1 year ago

hardwareadictos commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.