[GH-ISSUE #1402] [FEATURE REQUEST] Add semver versioning to docker tags

kerem commented

2026-02-27 08:17:31 +03:00

Owner

Originally created by @wuast94 on GitHub (Feb 24, 2026).
Original GitHub issue: https://github.com/lldap/lldap/issues/1402

Motivation
I track all my updates with renovate, and dates are very hard to track for almost everything.
Describe the solution you'd like
SemVer would add a defined way updates happen (Major Minor Patch) releases with proper release notes
That way it would also prevent to rollout breaking changes and such things or adapt to new features.

Describe alternatives you've considered
none

Additional context
none

Originally created by @wuast94 on GitHub (Feb 24, 2026). Original GitHub issue: https://github.com/lldap/lldap/issues/1402 **Motivation** I track all my updates with renovate, and dates are very hard to track for almost everything. **Describe the solution you'd like** SemVer would add a defined way updates happen (Major Minor Patch) releases with proper release notes That way it would also prevent to rollout breaking changes and such things or adapt to new features. **Describe alternatives you've considered** none **Additional context** none

kerem

2026-02-27 08:17:31 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 24, 2026):

There are already semver tags: v0, v0.6, v0.6.1

There hasn't been a release in a while, which may have confused you.

@nitnelave commented on GitHub (Feb 24, 2026): There are already semver tags: v0, v0.6, v0.6.1 There hasn't been a release in a while, which may have confused you.

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@wuast94 commented on GitHub (Feb 25, 2026):

well ok i didn’t scroll that far down, i was just seeing the date tags and also the latest tag which referrs to a dated tag. then i will switch to semver and hope nothing breaks xD

@wuast94 commented on GitHub (Feb 25, 2026): well ok i didn’t scroll that far down, i was just seeing the date tags and also the latest tag which referrs to a dated tag. then i will switch to semver and hope nothing breaks xD

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@wuast94 commented on GitHub (Feb 25, 2026):

followup question, will there be a new release in near future?

@wuast94 commented on GitHub (Feb 25, 2026): followup question, will there be a new release in near future?

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 25, 2026):

Are you looking for any specific feature that is in latest but not stable?

I haven't had time to do meaningful work recently on LLDAP, but there have been some contributions. I tend to do releases either on request or when something major drops.

@nitnelave commented on GitHub (Feb 25, 2026): Are you looking for any specific feature that is in latest but not stable? I haven't had time to do meaningful work recently on LLDAP, but there have been some contributions. I tend to do releases either on request or when something major drops.

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@wuast94 commented on GitHub (Feb 25, 2026):

i changed from 2026-02-24-alpine-rootless to v0.6.2-alpine-rootless
and got:

> Setup permissions..
chown: /app: Operation not permitted
chown: /app/bootstrap.sh: Operation not permitted

i run rootless in kubernetes with some security related options:
in the Deployment section:

securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        runAsGroup: 1000
        fsGroup: 1000

in the pod section:

securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: false
            capabilities:
              drop:
                - ALL

i would guess that there are a few changes that take place between thoose two tags(all commits in between?), but that was the one i faced

also the semver tag has 20 medium CVEs and the latest 6 Medium CVEs:

if i find time and if your intrested in i could help addidng automatic semver releases based on commit messages and also renovate to keep deps and other versiones up to date. i use this on my own projects to keep stuff up to date. This would also enable this project to help others maintain lldap becouse of proper release notes.

@wuast94 commented on GitHub (Feb 25, 2026): i changed from `2026-02-24-alpine-rootless` to `v0.6.2-alpine-rootless` and got: ``` > Setup permissions.. chown: /app: Operation not permitted chown: /app/bootstrap.sh: Operation not permitted ``` i run rootless in kubernetes with some security related options: in the Deployment section: ``` securityContext: runAsNonRoot: true runAsUser: 1000 runAsGroup: 1000 fsGroup: 1000 ``` in the pod section: ``` securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: false capabilities: drop: - ALL ``` i would guess that there are a few changes that take place between thoose two tags(all commits in between?), but that was the one i faced also the semver tag has 20 medium CVEs and the latest 6 Medium CVEs: <img width="981" height="133" alt="Image" src="https://github.com/user-attachments/assets/d1520c2a-1baa-4bab-a8f7-031e97be0e0d" /> if i find time and if your intrested in i could help addidng automatic semver releases based on commit messages and also renovate to keep deps and other versiones up to date. i use this on my own projects to keep stuff up to date. This would also enable this project to help others maintain lldap becouse of proper release notes.

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 26, 2026):

I'm not sure what you mean by automatic semver releases. Do you mean releases on a fixed cadence? I don't think this is right for LLDAP. Do you mean extrapolating whether there was an API break based on the commit messages? I would be wary of that (and you'd have to carefully consider what counts as a public API and what counts as a break -- I know I do, and release notes are carefully considered).

I could be talked into making a new LLDAP release, 0.6.3
I was hoping to have a plugin API to show for the next release, but the contributor who worked on that has been busy with other things the last... year.

@nitnelave commented on GitHub (Feb 26, 2026): I'm not sure what you mean by automatic semver releases. Do you mean releases on a fixed cadence? I don't think this is right for LLDAP. Do you mean extrapolating whether there was an API break based on the commit messages? I would be wary of that (and you'd have to carefully consider what counts as a public API and what counts as a break -- I know I do, and release notes are carefully considered). I could be talked into making a new LLDAP release, 0.6.3 I was hoping to have a plugin API to show for the next release, but the contributor who worked on that has been busy with other things the last... year.

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@nitnelave commented on GitHub (Feb 26, 2026):

Also, pardon me if I'm skeptical of those CVEs, but they usually just mean that one of the distant indirect dependencies has a specific usage mode that was discovered to be slightly unsafe with default settings. If you check what/how we actually use things, 99% of them end up not applicable.

Of course, we should still upgrade the dependencies (and I do), but it's not like I'm going to blast a message to everyone asking them to update LLDAP before I see a reasonable risk.

@nitnelave commented on GitHub (Feb 26, 2026): Also, pardon me if I'm skeptical of those CVEs, but they usually just mean that one of the distant indirect dependencies has a specific usage mode that was discovered to be slightly unsafe with default settings. If you check what/how we actually use things, 99% of them end up not applicable. Of course, we should still upgrade the dependencies (and I do), but it's not like I'm going to blast a message to everyone asking them to update LLDAP before I see a reasonable risk.

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@wuast94 commented on GitHub (Feb 26, 2026):

[DISCLAIMER] just ignore the application itself, its just Vibe Coded (im not a coder at all, im a sys admin)
git.wuastbude.de/vault/linkus@4c76d95876/CONTRIBUTING.md (conventional-commits)

so basicly it’s adding some steps in the workflow (GitHub actions) that looks at the commit message and builds a release from it.

as an example
feat(api): Some message would make a minor version bump
feat(api)!: Some other message would make a major release, the ! is marking it as a breaking change

https://git.wuastbude.de/vault/linkus/src/branch/main/.releaserc.json
this is the file that defines what keyword defines the type of version bump, for example feat would mostly be a minor release, while docs wouldn’t create a release at all and refactor would be a patch release. Its completely up to the project how its defined.

for completeness my workflow file, something i should clean up a bit but it works so nothing i priotize xD https://git.wuastbude.de/vault/linkus/src/branch/main/.gitea/workflows/release.yaml

so its not "automatic", its more an automation that reacts on commit messages in a well defined way. and renovate just plays nicely together with that becouse its an easy way to keep deps and versions up to date, i automerge patch updates which automaticly build a new release which then gets auto deployed in my cluster, but i could also make every step manual checked before or just use it as a guide.

Hope i could clarify a bit what i mean, what it does, and how it work 😊

About the CVEs, it wasent meaned like "OH MY GOOD ITS INSECURE", it was just an observasion 😊 most widly used projects out there have tons of CVEs which mostly arent relevant at all even if Critical, i look at critical ones yes and try to keep my stuff clean but that’s it.

@wuast94 commented on GitHub (Feb 26, 2026): [DISCLAIMER] just ignore the application itself, its just Vibe Coded (im not a coder at all, im a sys admin) https://git.wuastbude.de/vault/linkus/src/commit/4c76d95876c594a70a55a712f68c03fbccc426e1/CONTRIBUTING.md#conventional-commits so basicly it’s adding some steps in the workflow (GitHub actions) that looks at the commit message and builds a release from it. as an example `feat(api): Some message` would make a minor version bump `feat(api)!: Some other message` would make a major release, the `!` is marking it as a breaking change https://git.wuastbude.de/vault/linkus/src/branch/main/.releaserc.json this is the file that defines what keyword defines the type of version bump, for example feat would mostly be a minor release, while docs wouldn’t create a release at all and refactor would be a patch release. Its completely up to the project how its defined. for completeness my workflow file, something i should clean up a bit but it works so nothing i priotize xD https://git.wuastbude.de/vault/linkus/src/branch/main/.gitea/workflows/release.yaml so its not "automatic", its more an automation that reacts on commit messages in a well defined way. and renovate just plays nicely together with that becouse its an easy way to keep deps and versions up to date, i automerge patch updates which automaticly build a new release which then gets auto deployed in my cluster, but i could also make every step manual checked before or just use it as a guide. Hope i could clarify a bit what i mean, what it does, and how it work 😊 About the CVEs, it wasent meaned like "OH MY GOOD ITS INSECURE", it was just an observasion 😊 most widly used projects out there have tons of CVEs which mostly arent relevant at all even if Critical, i look at critical ones yes and try to keep my stuff clean but that’s it.

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@wuast94 commented on GitHub (Feb 26, 2026):

and in general, i dont ask you to do it this or that way and i never would. i completely respect your opinion in any way. your project your decision 😊 we (mostly)all do this in our free time, i love what projects like this and many others offer and what they enable us to do. completely for free! so i respect any decision taken, if i like them or not 😊

@wuast94 commented on GitHub (Feb 26, 2026): and in general, i dont ask you to do it this or that way and i never would. i completely respect your opinion in any way. your project your decision 😊 we (mostly)all do this in our free time, i love what projects like this and many others offer and what they enable us to do. completely for free! so i respect any decision taken, if i like them or not 😊

kerem commented

2026-02-27 08:17:32 +03:00

Author

Owner

@martadinata666 commented on GitHub (Feb 26, 2026):

i changed from 2026-02-24-alpine-rootless to v0.6.2-alpine-rootless and got:
> Setup permissions..
chown: /app: Operation not permitted
chown: /app/bootstrap.sh: Operation not permitted
i run rootless in kubernetes with some security related options: in the Deployment section:

This part probably accidentally deployed standard image rather that rootless, because rootless image won't setup permission.

@martadinata666 commented on GitHub (Feb 26, 2026): > i changed from `2026-02-24-alpine-rootless` to `v0.6.2-alpine-rootless` and got: > > ``` > > Setup permissions.. > chown: /app: Operation not permitted > chown: /app/bootstrap.sh: Operation not permitted > ``` > > i run rootless in kubernetes with some security related options: in the Deployment section: > > ``` This part probably accidentally deployed `standard` image rather that `rootless`, because rootless image won't setup permission.

kerem referenced this issue

2026-02-27 09:09:42 +03:00

[PR #488] [MERGED] server: return groups in memberof by cn instead of uid #776

Rows
Columns

[GH-ISSUE #1402] [FEATURE REQUEST] Add semver versioning to docker tags #488