-
|
Having searched the repository and the docs, I can't find any information on LubeLogger's versioning. How is it versioned? It seems to partially adhere to semantic versioning, with the main exception being that patch and minor version increases seem semi-arbitrary and often don't match up with what's changed in the release. For example, 1.4.2, released after 1.4.1, saw a number of significant feature additions, and even a small breaking change in the webhook payload schema. Personally I wouldn't quibble over making this a major release due to the webhook payload schema change, but it feels worthy of a minor version bump at least (e.g. 1.5.0). I hope you don't take this the wrong way, my intention is not to argue or accuse, simply giving an example to hopefully better illustrate my query (how is LubeLogger versioned?). Whilst I am a big fan of semantic versioning, I have no issue with a project not following it. I'd just like to understand what it does follow 😄 As always, thank you for all your work. LubeLogger has been, is, and will no doubt continue to be one of my favourite self-hosted applications! ❤️ |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
I think we started off being somewhat committed to doing semver but about halfway through we started to just increment the smallest number if there isn't any breaking changes or if it's super minimal. Case in point with the webhook payloads, the initial implementation was pretty bad and we didn't really know how it's being consumed, so we just kinda assumed that users were just logging the username and the action data from the payload with no logic dependent on them. We tried to preserve some backward compatibility but uhh...hard to foresee breaking changes if we don't know how it's being used in the first place. So I'd say LubeLogger's versioning is kinda semver(?) except instead of I know it seems like the versioning is just us incrementing the smallest number to 9 and then incrementing the middle number, but there is actually a reason for that, and it's because in our opinion, a lot of small increment changes across a period of time adds up to medium risk if the user is using a very outdated copy of the software. So, an upgrade from 1.3.9 to 1.4.0 is generally very small risk, an upgrade from 1.2.0 to 1.4.0 would be considered medium risk. If we do roll out a medium risk update we'll most definitely increment the middle number, so it can potentially jump from 1.4.2 to 1.5.0, if the current version is 1.4.9, we'd probably do something like 1.5.9/1.6.0 instead so that it conveys the right message to the user that the bigger the jump between the version number the bigger the risk for updating. |
Beta Was this translation helpful? Give feedback.
-
As a creator/maintainer of some open source projects, I totally get this, especially in the early stages of a project it can be tough! Overall this is a great explanation, totally understood. Thank you! |
Beta Was this translation helpful? Give feedback.
I think we started off being somewhat committed to doing semver but about halfway through we started to just increment the smallest number if there isn't any breaking changes or if it's super minimal.
Case in point with the webhook payloads, the initial implementation was pretty bad and we didn't really know how it's being consumed, so we just kinda assumed that users were just logging the username and the action data from the payload with no logic dependent on them. We tried to preserve some backward compatibility but uhh...hard to foresee breaking changes if we don't know how it's being used in the first place.
So I'd say LubeLogger's versioning is kinda semver(?)
except instead of
majo…