Official [User Feedback Requested] Addressables Content Update Workflow Improvements

I am not sure if the following related to this thread or not.
Anyway our project use git to manage the source code. so the main issue here is when we switch the branch, the content update will fail for both dynamic and static contents. That is because the Addressable content update relies on the contents build in Library/com.unity.addressables folder, which usually excluded from git management. I have to copy all the contents from that folder to keep my content update success among different branches. I hope the new workflow could make this more reliable.

 

The main problem I see with the "bundle update content" workflow seems to be that there is no separate (i.e. cartesian product) dependency tracking per:

• Target platform
• Target build (e.g. devel/testing/feature branch/staging/release)

The former makes it useless for most non-trivial cross platform uses. Like, seriously, who has the same bundles on Android and iOS and rolls out updates for either perfectly in sync?

The latter makes it useless for most production scenarios where you're (hot-)fixing a iOS release branch in the morning and your Desktop beta branch in the evening... Haven't been able to hold on to any updated catalogs once it's time to merge these hotfix branches into devel, so I just always delete and rebuild from scratch for every release. I end up tracking compatibility manually through configs and via CCD labels, which clearly isn't desirable nor robust.

I'd recommend a reverse workflow:

• Build the full artifacts (bundles etc.) and catalogs for each platform and target. Straightforward, just package everything that is in a group for a catalog.
• Calculate deltas to all previous preexisting and upgradeable addressable bundles in the destination folder as a post build step. This should be a very simple operation, basically a dictionary intersection on the catalog and a clean write of the resulting "patch" bundle. Practically resolvable at the I/O speed of the underlying hard drive.
• Deploy both the full fat catalogs and bundles as well as all patch deltas in the bundles folder for use with Unity CCD et.al.

Developers will manually delete or mark as deprecated obsolete catalog/bundle sets in the artifacts directory, meaning no new deltas are prepared for these. Legacy clients with older catalogs will fall back to local only or full new remote catalog or request a forced client update before continuing (this behaviour should be an enum, default is the throw and let client display forced update dialog behavior).

Another request is to please make local catalogs optional, or better even, treat them the same as remote, and allow creation of multiple remote catalogs. (as catalogs themselves tend to get large). A local catalog is local because it is loaded locally, a remote one is remote because it is loaded remotely. They are (and for most intents currently can) be used interchangeably, so there is no need to duplicate them as the system currently does, and locking local catalogs away in AssetDatabase.

My fix was a very limited local catalog in the main project, and a proper one for remote only usage in a separate project. It would have been very desirable to not have to use two projects for that, but the normal local catalog behaviour is that it would have Infos about ALL the content that is remote. I'd want to load and download that info in increments, too, i.e. multiple remote catalogs entirely disconnected from the local catalog.

And pease give us a smarter build and bundle versioning system. (the output of git describe --always would be a good inspiration, assuming the repository has Tags following semver principles)

 

Did you guys fix the issue with Check for content update restrictions detecting changes when assets didn't change? I currently cannot push my content update to my production game because Addressables detects changes in assets that are identical

EDIT: the hash changes were caused by line endings differences in meta files between my 2 machines. Those changes are not picked up by git, which made me convinced the assets were identical. Addressables could show a warning if the only changes are line endings

 

Same here, this prevent us from making a proper content update, how to deal with this?