mirror of
https://github.com/actualbudget/actual.git
synced 2026-07-11 11:59:55 -05:00
[Feature] Semantic version #523
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/actual#523
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @webysther on GitHub (Jul 23, 2023).
Verified feature request does not already exist?
💻
Pitch: what problem are you trying to solve?
When using this software I found no MAJOR and MINOR separation as is usual on mostly software by using semantic version, this is critical because when you want to update the software you may want to only update with non-breaking changes and with docker this is very simplified with MAJOR tags, like in the postgres, for instance:
Describe your ideal solution to this problem
Starting using semantic version with date also, like described in spec: https://semver.org/#spec-item-10
For this project this can be done in this way:
The PATCH can be ignore because the project only use one actually, with MAJOR and MINOR is a advance.
This make possible to create a MAJOR tag in docker also:
actualbudget/actual-server:24actualbudget/actual-server:24.1Teaching and learning
This make possible to users update the software only with non-breaking changes, updating the manual to starting using the MAJOR tag as default and not the latest as suggested.
@github-actions[bot] commented on GitHub (Jul 23, 2023):
✨ Thanks for sharing your idea! ✨
This repository uses lodash style issue management for enhancements. That means enhancement issues are automatically closed. This doesn’t mean we don’t accept feature requests, though! We will consider implementing ones that receive many upvotes, and we welcome contributions for any feature requests marked as needing votes (just post a comment first so we can help you make a successful contribution).
The enhancement backlog can be found here: https://github.com/actualbudget/actual/issues?q=label%3A%22needs+votes%22+sort%3Areactions-%2B1-desc+
Don’t forget to upvote the top comment with 👍!
@j-f1 commented on GitHub (Jul 23, 2023):
How would you define a breaking change in the context of this project?
@webysther commented on GitHub (Jul 25, 2023):
Great questions @j-f1, every change that need the user to change something to upgrade (manual database migration for instance when a new release for docker), a change of how the user interact with application, like a new default behavior which is common in some cases. A huge release which maybe introduce new bugs because have new big features that is on by default and don't work as a feature flag. Breaking changes like a new ENV VAR required, a structural change that need to execute a tool to fix a old bug discovered only in future. Some applications consider MAJOR when the UX is changed a lot.
But normally is all user required intervention that maybe break the app if they did automatic.
Anothe common example is change on API, because if anyone use the API to create automation, the new version maybe will break the workflow/integration created, like endpoint renamed/deprecation.
@j-f1 commented on GitHub (Jul 25, 2023):
Thanks for that thorough list! I’m not sure any of them really apply to us:
We always run database migrations automatically when necessary.
We do our best to avoid major changes to the UI that break existing workflows, and I’m not sure doing a major release for smaller UI changes would make much sense. (For example, most releases would probably break at least some automations that rely on clicking hardcoded pixel coordinates, but that feels fine).
This is why we use feature flags! I don’t see us shipping any major features without using one in the future.
I don’t foresee us requiring configuration like this in the future.
Anything like this would be able to be communicated more clearly via the UI than via version numbering (and presumably we would want to get people to update ASAP to fix the bug, so the fix would be automatic)
We probably won’t do this in the future, but it’s definitely something to keep in mind. The current UX has worked well for 4–5 years already, and I don’t see a need to change it now.
One of our big goals is making Actual easy to use even by people who aren’t very technical. Part of that is building an app that is capable of handling any changes needed when updating.
Since the API is distributed as a separate package, it is versioned separately and uses standard semver practices. We’ve already released a couple of major releases as needed.
The closest thing to a breaking change we’ve had is that a while ago we started requiring HTTPS in order to access the web app in some cases. This was only introduced because we discovered the fallback mode we were using had major issues that led to user complaints. After getting feedback from people that they still wanted to use the broken version, we did a bugfix update to allow folks to bypass the warning instead of blocking them from using the app.
@webysther commented on GitHub (Jul 25, 2023):
Thanks for the detailed response, I think I'm lost in the woods, this docker here is the frontend and backend? Because I open this issue thinking that only one repository.
@j-f1 commented on GitHub (Jul 25, 2023):
The Docker image is for the backend, but it includes a frontend bundled with it that you get when you visit it once started. We generally release the frontend and backend together at the same time.
@webysther commented on GitHub (Jul 26, 2023):
Thanks, sorry for the burden, great piece of software, I have a 12 year old spreedsheet and the first time I look for a software that fits what I want.