I recently got into a situation where using anything other than Transmission 4.0.6 would be ideal (it’s blocked due to a bug) and looking into things, I noticed two different app versions - the Transmission version and another one. What is this version relating to? The Docker container version? An arbitrary version of the TrueNAS SCALE app? Is there a compatibility matrix of sorts showing which iX(?) version corresponds to which app version and the like?
Speaking of, is there a way to install an older version of the application? I currently only have 2 older snapshots available (I think 1.17 is installed, 1.16 and 1.15 available), but as per my testing, all three of them are Transmission 4.0.6. Is there a way to install Transmission v4.0.5 other than a custom app?
I doubt it. Theoretically you could look back in the modification history of a catalog version of an app like History for trains/community/transmission - truenas/apps · GitHub to try to find when the App Version was last updated (though I don’t know if there is actually a way to specify an earlier version when installing the app in the UI in many cases) but especially in this case considering that Transmission 4.0.6 was released months before TrueNAS 24.10, I doubt there was ever a docker catalog version of the app using that version.
I’m trying to do the same thing, transmission 4.0.6 was banned on a pretty know tracker and it’s unusable now.
The only workaround I found is to install a custom app or move to dockage or portainer.
A feature to choose the app version is very important sometimes and shouldn’t be too hard to implement.
Looking at the transmission Scale docker app history, 1.0.0 (september-ish) was using 4.0.5, didn’t browse through to see when it changed to 4.0.6.
4.0.6 is the latest version, so you can’t blame the community app repo maintainers for this.
Also, the private tracker ban has been going on for a long time and still no update on the tranmission github issue. Maybe think about switching to a different bittorrent client?
You could just install an older version with a custom app (either UI or custom yaml).
I’m thinking of changing to a different client, but the feature in the Truenas would be nice to have.
I already have 2-3 custom applications, so if I have to move one more…maybe it would be better to move completely to another container management solution.
This is what I’m thinking too. With the way networking is managed (or rather said limited - I had to choose Host network for Plex to finally be reachable from the outside through pfSense) you’d get a lot more freedom going full custom. But I said I’ll give it the old try with the built-in apps first. And I’m hoping something similar to PVE helper scripts might be available with Fangtooth and the Incus implementation bringing hopefully a final container solution.
I figure it’s best if I reply here vs. opening a new topic (unless this won’t be seen), but the app versions came into a clear spotlight just today when I saw both my Plex and Transmission apps had the option of an update.
Not sure what the update with Plex was, maybe it was a version bump, but Transmission stayed at v4.0.6 with only the TrueNAS SCALE app raising the version number. Both Transmission and Plex also had ‘no changes’ in the changelog.
I looked on github and there is no more info regarding changes between versions there too, just the latest 1.1.18 Transmission app folder with no older versions.
You’d need to dig in the yaml in the Scale app repo to see what image they are using. Even though EE is using docker, there is a ton of templating still going on with the catalog apps. So it’s very possible apps will have updates that are in no way associated with the container image.
I’d imaging it’s their intention since they do have that +changelog area in the update UI. Probably something that hasn’t been fixed after the change to Docker.
I think I can add a bit of clarity here. What is probably happening when you notice an updated (catalog) Version but the (upstream) App Version remains the same is that there has been an underlying update to the Apps library itself. Due to the way the library templating works, any changes to the rendering engine, such as adding a new field that can be used on one or more app configuration screens, results in a bump to the library version. Every app in the catalog then needs a corresponding bump to be consistent with the updated library.
So in many cases the Version bump you see may reflect nothing more than a number change for that particular app, while the actual changes made in that library update affect a different app or apps. Until the overall library is more mature and stabilized, frequent changes like this are inevitable.
As for the changelogs, as you can probably infer, the amount of work that would go into manually creating changelog entries for every app in the library when these changes occur isn’t really tenable. There was initially interest in providing something like that, hence the element in the UI, but it’s not realistic. Instead, work is in progress to make that app update dialog more useful and informative using programmatically generated information.
