In terms of rollback in a profile that has library inheritance, I guess my issue is that it does not technically exist. You can fix-forward by reverting to older snapshots of various libraries / the profile itself but the concept of a true rollback is not one that's been implemented, but presumably could be..?
Each publish produces a distro bundle, to enact a genuine rollback you would simply need to push an older distro to the CDN, perhaps sensibly constrained such that only a previous prod build could be pushed to prod.
Then for the more granular stuff, when to inherit etc., for me I think it makes the most sense to have some sort of timeline tool not unlike the current client-side versions feature, which in a profile would give you the ability to look across all the inherited libraries, and using a master slider pick a point in time at which to inherit the latest (at that point) version that's eligible for inheritance. And then beneath that, library-level sliders that would allow the user to set custom inheritance on a specific library if they so wished.
The default would always be "current", and maybe the standard behaviour would be that the slider snaps to profile publish events, so the simple-mode experience is that you can simply drag the whole set of inherited libraries to their state at a given publish within your profile. But the complex-mode experience would let you pick any moment in time, and split those timings by library.
Use case would be - three days ago I performed a production publish and one of the tags that's been configured in an inherited library is leaking a data item to a vendor that they should not be receiving, and it's severe enough that I want to be able to perform a fix without reverting the entire publish. But time has passed, new features have dropped in other inherited libraries ready for the next scheduled publish, but I need to perform a hotfix now to sort this one issue and I'm not intending to launch any new features. The owners of the affected library have ensured that what's published there today is what was in the last release, plus the fix, nothing else, but I can't go around another five teams' libraries reverting everything they've done this week, perhaps I shouldn't even have the access to do so. So, I go into the Timeline view in simple-mode, drag the master slider back to our last production publish, enable complex-mode, and then find the affected library and drag its slider to "current". Now the content of my publish is the inherited libraries at their position at my last publish except for the one library that requires an update, which is inherited in its current state.
The way I'm envisaging it working in the backend would be effectively that each library publish is in effect a commit to the branches (environments) to which it's published. From my profile I don't see details of the development branches that users within the library are using to manage their own code, but I do see a stream of commit/publish events that I can roll back to a specific point in time for the purposes of what I'm inheriting.
I'm probably just reinventing Git submodules or something, so this might all be terribly derivative, but you get the idea..
Bonus feature: The ability to specify for a given publish what the minimum version of other libraries/profiles within the account needs to be for that publish to work. Because interdependencies between inherited libraries do exist and they're awkward. If I make a change to my Webchat library to enable a new supplier and my Analytics library contains code that adds event listeners to the new webchat dialog, I need to be able to specify within my Analytics library that a given publish expects that the Webchat library will be at least as recent as insert date here. Or use tags as sort of feature flags so that you have a dependency on a specific tag being present in the other library, I dunno.. but what you want to avoid is a scenario in which an interdependency between two libraries is a) not made visible to users and could be forgotten about and b) cannot cause weird side-effects if one library is rolled back and another that depends on now-reverted code isn't rolled back.
And finally, the feature I'm describing above would also work for maintaining stable releases vs nightly release tracks etc., wherein you might have a main profile that takes the most recent version of every library it inherits, and a near-identical main-stable profile that has all its sliders fixed at a given point in time, only moved when a new version is considered stable having been shown to be issue-free in production. "Can't you just do that already, freezing the stable version by not publishing the profile?" you might ask, and not quite, because at the point of publishing that profile, you're getting all the absolute latest versions of the libraries, which might not be the versions that you want to include in your stable release. Furthermore, if you needed to make any reference data changes (e.g. update a marketing tag campaign ID that has expired) without functional code changes, you'd have to re-inherit the whole set of libraries at their current state including all code.
... View more