github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-05 22:52:20 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #1388] [Feature] Semantic version #7463

New Issue
Closed
opened 2026-04-10 17:18:28 -05:00 by GiteaMirror · 7 comments
GiteaMirror commented 2026-04-10 17:18:28 -05:00
Owner
Copy Link

Originally created by @webysther on GitHub (Jul 23, 2023).
Original GitHub issue: https://github.com/actualbudget/actual/issues/1388

Verified feature request does not already exist?

  • I have searched and found no existing issue

💻

  • Would you like to implement this feature?

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:

image

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:

  • 24.0+2023.3
  • 24.1+2023.3

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:24
  • actualbudget/actual-server:24.1

Teaching 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.

Originally created by @webysther on GitHub (Jul 23, 2023). Original GitHub issue: https://github.com/actualbudget/actual/issues/1388 ### Verified feature request does not already exist? - [X] I have searched and found no existing issue ### 💻 - [X] Would you like to implement this feature? ### 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](https://semver.org/), 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: ![image](https://github.com/actualbudget/actual/assets/750007/26fab973-65d6-4340-a673-0191709f7aaa) ### 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: - 24.0+2023.3 - 24.1+2023.3 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:24` - `actualbudget/actual-server:24.1` ### Teaching 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.
GiteaMirror added the feature label 2026-04-10 17:18:28 -05:00
GiteaMirror commented 2026-04-10 17:18:31 -05:00
Author
Owner
Copy Link

@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 👍!

<!-- gh-comment-id:1646739810 --> @github-actions[bot] commented on GitHub (Jul 23, 2023): :sparkles: Thanks for sharing your idea! :sparkles: 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 👍! <!-- feature-auto-close-comment -->
GiteaMirror commented 2026-04-10 17:18:31 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Jul 23, 2023):

How would you define a breaking change in the context of this project?

<!-- gh-comment-id:1646818142 --> @j-f1 commented on GitHub (Jul 23, 2023): How would you define a breaking change in the context of this project?
GiteaMirror commented 2026-04-10 17:18:32 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:1648824684 --> @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.
GiteaMirror commented 2026-04-10 17:18:32 -05:00
Author
Owner
Copy Link

@j-f1 commented on GitHub (Jul 25, 2023):

Thanks for that thorough list! I’m not sure any of them really apply to us:

manual database migration for instance when a new release for docker

We always run database migrations automatically when necessary.

a change of how the user interact with application, like a new default behavior which is common in some cases.

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).

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.

This is why we use feature flags! I don’t see us shipping any major features without using one in the future.

Breaking changes like a new ENV VAR required

I don’t foresee us requiring configuration like this in the future.

a structural change that need to execute a tool to fix an old bug discovered only in 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)

Some applications consider MAJOR when the UX is changed a lot.

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.

But normally is all user required intervention that maybe break the app if they did automatic.

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.

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.

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.

<!-- gh-comment-id:1649688987 --> @j-f1 commented on GitHub (Jul 25, 2023): Thanks for that thorough list! I’m not sure any of them really apply to us: > manual database migration for instance when a new release for docker We always run database migrations automatically when necessary. > a change of how the user interact with application, like a new default behavior which is common in some cases. 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). > 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. This is why we use feature flags! I don’t see us shipping any major features without using one in the future. > Breaking changes like a new ENV VAR required I don’t foresee us requiring configuration like this in the future. > a structural change that need to execute a tool to fix an old bug discovered only in 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) > Some applications consider MAJOR when the UX is changed a lot. 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. > But normally is all user required intervention that maybe break the app if they did automatic. 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. > 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. 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.
GiteaMirror commented 2026-04-10 17:18:33 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:1650226700 --> @webysther commented on GitHub (Jul 25, 2023): Thanks for the detailed response, I think I'm lost in the woods, [this docker here](https://actualbudget.org/docs/install/docker/) is the frontend and backend? Because I open this issue thinking that only one repository.
GiteaMirror commented 2026-04-10 17:18:35 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:1650341070 --> @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.
GiteaMirror commented 2026-04-10 17:18:37 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:1651016352 --> @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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#7463
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?