stavros-k
commented
2 years ago It’s a double breaking release from both our chart and the upstream project
Closed yottabit42 closed 2 years ago
stavros-k
commented
2 years ago It’s a double breaking release from both our chart and the upstream project
yottabit42
commented
2 years ago Ok, does that mean it will not be fixed? As the app itself does not allow restores of backups from prior versions, I guess I will just need to set it up from scratch in the new version.
StevenMcElligott
commented
2 years ago Anytime there's a breaking change you will likely have to set it up from scratch, especially seeing as this is a change upstream (the app itself) and in our chart. Same thing applies if an app moves trains (from incubator to stable and etc. So it's not "not fixed", it's basically stay at your old version or start a new installation
PrivatePuffin
commented
2 years ago Please next time file a ticket on discord accordingly, unless you've some evidence there is a code issue. "Not worky" is not really something we can accept bugreports for and 99% of cases it's usererror.
yottabit42
commented
2 years ago As an end user of the product, I didn't just write "not worky" and followed all the guidelines for logs. No reason to be rude.
Also as an end user, and this is probably outside of TrueChart's control, but perhaps a feature request that could be made to TrueNAS, is to block/hide upgrades from breaking change versions. For instance it's known now that this app upgrade path doesn't work, due to multiple reasons, so it would be nice if the upgrade option was removed from the UI for this version edge, since the upgrade "not worky."
shadofall
commented
2 years ago or people could realize that major revision number changes (app version or chart version) = possible breaking change. flip side while you cant import your backup to restore all the settings. you can import the backup to restore recipes using the migration option as per document on the applications site.
StevenMcElligott
commented
2 years ago As an end user of the product, I didn't just write "not worky" and followed all the guidelines for logs. No reason to be rude.
Also as an end user, and this is probably outside of TrueChart's control, but perhaps a feature request that could be made to TrueNAS, is to block/hide upgrades from breaking change versions. For instance it's known now that this app upgrade path doesn't work, due to multiple reasons, so it would be nice if the upgrade option was removed from the UI for this version edge, since the upgrade "not worky."
A lot of this is outside control, but he wasn't rude. Basically stated that Discord is the best place for this unless it's really "our" issue, and the changes in the PR you linked shows it's basically a new chart with new release versions, we can't guarantee updates in between major version in the app/chart.
yottabit42
commented
2 years ago @shadofall thanks for the pointer there. I was able to use the migration feature to import my old backup. It wasn't obvious in the Mealie UI that this was an option, as one wouldn't immediately think that migration from other recipe databases would include prior versions of Mealie itself.
@StevenMcElligott I understand the point. It's just not obvious to an end user that using the UI's built-in upgrade feature should be expected to fail in any circumstance. Thus, I expected this was an issue with the upgrade pipeline, not a breaking change where I should expect the upgrade to lose state. Now I know, but I am sure this will continue coming up forever with the current method in the TrueNAS UI.
Thanks everyone!
PrivatePuffin
commented
2 years ago As an end user of the product, I didn't just write "not worky" and followed all the guidelines for logs. No reason to be rude.
I'm not much a fan of terms like "end user of the product". Because in my opinion it sounds like you expect a reply like customer of a product would, which is simply almost never what you're going to get with free (as in beer) software.
Anyway: What I tried to explain is that "failed to deploy" is basically similair to "not worky". We don't want to burden our developers, with verifying vague reports of "something", "not working".
We have very clear support procedures in place, in case people experience something not working correctly, which sometimes advice to file a bugreport. As our limited amount of maintainers is not able to also verify each and every user that reports a "not working" app, which 99% of cases ends up being user error.
@StevenMcElligott I understand the point. It's just not obvious to an end user that using the UI's built-in upgrade feature should be expected to fail in any circumstance. Thus, I expected this was an issue with the upgrade pipeline, not a breaking change where I should expect the upgrade to lose state. Now I know, but I am sure this will continue coming up forever with the current method in the TrueNAS UI.
To be 100% clear: SemVer is our choice, not all projects follow semver. For example: some use CalVer or a variant of that (like iX Systems). So it's not something iX is likely te put into the GUI.
It's your responsibility to read the changelog on upgrade, though we agree our changelog needs work to more clearly/cleanly define breaking change update (aka major version increases). But byond that, there is not much we can do. But besides that "breaking" just means "something might break", it does not mean "verified to be breaking something", so completely hiding things away on each major upgrade would also be silly.
In the end, we are making design decisions for the Apps, but we're also allowing Apps we deem "trash quality" or "unstable". We've decided that we leave it to the user to decide what they want to install and upgrade, hence we expect users to read the docs and changelogs of everything they install.
In the future we will be dedicating a seperate train for things we've verified, thoroughly tested and take more responsibility for (from a security and stability perspective).
So in that regard: we're not likely to do anything with this feedback and I expect neither is iX (actually: I discussed that previously a year ago and no, I personally did not agree there).
truecharts-admin
commented
1 year ago This issue is locked to prevent necro-posting on closed issues. Please create a new issue or contact staff on discord of the problem persists
App Name
Mealie
SCALE Version
22.02.4
App Version
0.5.6_9.0.3 -> 1.0.0beta_10.0.4
Application Events
Application Logs
Application Configuration
All defaults.
Describe the bug
I have a working Mealie deployment version 0.5.6_9.0.3. I am attempting to upgrade to 1.0.0beta_10.0.4.
Attempts to upgrade this instance result in the container never deploying successfully (stuck on deploying 1/2). However, deploying a new instance with the same version is successful. Looking at the logs, I assume that the database migration process from old to new is causing a problem. If I rollback to the prior version of the instance it still works fine.
To Reproduce
Expected Behavior
Upgrade is successful, recipes are maintained, user login is maintained.
Screenshots
n/a
Additional Context
May be related to issue #3752.
Rollback to old version is successful.
I've read and agree with the following