Bucket System Design Question

I'm working on designing the way we'll structure our buckets for production and it's lead me to two potential systems. There is a player that gets built for each "mod" that has its content stored in asset bundles. So there may be 16 different builds out in the wild at any moment and my system needs to be robust enough that someone creating new asset releases won't break one any of those players. As it stands if I create a new CCD release I can end up breaking my other builds as the content for every mod is in the same bucket.

My first idea is to point the RemoteLoadPath of the build to a badge that contains the build number and apply that badge to the CCD release for that player. So build 5 will look for the content release with badge 5. That content release would only have the assets required for whatever mod build 5 is.

The second would be to have two separate buckets for each mod and do the usual dev/production bucket setup for them.

The system I choose really just depends on how CCD is intended to be used. If release 6 on a CCD bucket is being used for a build somewhere and we're all the way up to release 600, will release 6 be purged for server storage? Is there a limit I need to keep in mind for how many content releases are stored by one bucket before deletion?

If I use the second method, is there a limit to the number of buckets I can have?

At the moment the number of "mods" that will be distributed with their own player build is about 6 but may grow to 30 or more over time. I want to plan around this and not use the service in a way that is unintended or potentially TOS breaking.

 

I ended up implementing the system of having a unique badge per build using GUIDs so now there is only one bucket per platform.