Make old revisions of elements editable in different development libraries

[#1]

If I have different libraries I would like to be able to edit the revisions of rules, data elements etc. in all libraries. Unfortunately only the latest revision can be edited. And the latest revision is always the same that is edited though the interface.

Two options would be could:

1. "Set as latest revision" from the library interface
2. Switching the Working Library shows the Revisions of the library in the interface

When editing e.g. a rule again saving would create a new latest revision.

[#2]

The revisions themselves are set in stone at the time they are saved to a library and they are never edited again.  This is a system constraint so that you can always have a historical record of the thing that was published at any given time.

When you say that you want to make it editable, can I describe that a little bit differently and see if it does what you need?  What you'd like to do is take a revision as it existed at some point in time, and then make that the version that shows up in the regular list view so you can use it as a base for changes that you want to make moving forward?

[#3]

Yes, I want to make changes based on a previous revision not from the latest.

If I have different libraries that have changes of e.g. the same rule I would see those as different branches of the rule. At the end maybe one of those will be discarded or I chose to merge them.

[#4]

With Launch, we deliberately shied away from branching.  You should think of all your resources as existing within a single branch.  Each time you save a resource and add it to a library, an individual commit to each individual resource is made.  And a library is not a different branch, it's more like a list of specific commits for the individual resources inside of it.

So what you can do is take a historical commit and bring it back to HEAD to make it the working version.  You can then make new edits, and make new commits (add to a Library).  But because there is concept of branching, there is no concept of merging back.

I obviously don't usually talk about things this way, but I think it's a decent description.  For more details on the process of "reverting" or bringing a revision back to HEAD to make it the working version, you can read up on Compare View: Compare resource revisions .  The "Use These Changes" button will do that part for you.

[#5]

Thanks for the explanation and the hint regarding revision comparision. But that means if I (or two persons) work simultaneously on different versions of a rule each one will and needs to create new revisions. In the end this means that e.g. revision 1,2 are from V1 and revision 3,4 are from V2 and revision 5 from V1 again and revisions 1 to 5 do not reflect a step by step evolution of the element. And currently working on V1 I need to remember that revision 2 (and not 3 or 4) is the last version. I can imagine that this can lead to confusion in the future. But maybe it is just while building a new and first Launch setup with testing different approaches and in production this will be fine with your mentioned resource comparison.

At least I could imagine it being helpful to have the options after selecting a different working library to recreate all or multiple rules and data elements as the latest revision. Does this make sense to you?

[#6]

You are right that when two people are making edits at the same time, and adding them to libraries, you could end up in a scenario where the sequential revision history doesn't look like it makes any sense.  From what we have seen so far, that doesn't happen a ton in practice (at least we haven't seen people complain about it much), this we haven't prioritized treating it any differently yet.

To your other point,can you describe that a bit more?  You're thinking maybe from the list view you'd select multiple items and add them to your working library?  Can you help me understand the problem that helps you solve?

[#7]

Let me try to describe an example I currently confronted with.

At the moment being in the interface the rules and data elements lists show the latest revision of each item belonging to Library A. There are Rule 1 (Revision 27) and Rule 2 (Revision 13). Same would apply to Data Elements. Now I want to make changes to Library B that builds upon previous revisions. My current workflow is the following:

1. Navigate to Publishing
2. Open Library B
3. Identifying Rule 1 (Revision 13) and Rule 2 (Revision 12)
4. Changing the Working Library to Library B
5. Navigate to Rules
6. Select Rule 1
7. Compare Revisions
8. Select Revision 13 and "Use These Changes"
9. Repeat 6-8 for Rule 2

Now I can edit Rule 1 and 2 of Library B again and save them as the Latest Revision.

Also I could accidentally edit another Rule that still shows up in the Rules list and Click "Save to Library and Build" that did not even belong to Library B.

Also for Step 6 Compare Revisions I had to look up the recent revision of Library B before from the "Edit Library" interface.

A workflow I could imagine:

1. Changing Working Library while being e.g. on the Rules list
2. Click "Select recent revisions from Working Library as latest revisions"

Now I have Rule 1 (Revision 13 of 27) and 2 (Revision 12 of 13) in the list and can edit them.

Additionally I could imagine to see a status of "Not used in Library" for Rules that are not part of the working library.

Alternatively or additionally to step 2 it would be possible to see the status "Differing Revision" and then: Multi Select the rules that differ (maybe even select by this criteria if there is a long list) and have the option "Select recent revisions from Working Library as latest revisions".

And if I still want to compare individual revisions it would be great not to see only Revision 1, Revision 2, in the pull down but also to have the option and/or notes to which library a revision belongs. Or even to chose "Revision of Library B"  in the pull down or better an a filter "Show only revisions built to Library B".

Alternatively this could happen from the "Edit Library" interface.

1. Chosing "Save & Build for Development" or just "Save" (this automatically creates a new Latest revision for items in the library that have an older revision).
2. Navigate to Rules (then like upper example workflow)

Is this comprehensible? Did I maybe just miss some option somewhere? At least my current workflow feels comlicated to jus edit the state of specific library.

[#8]

Thanks for taking the time to write it all out.  I think I understand, and if I do, it sounds like what you're really wanting is to treat a Library (or a Working Library) more like a true branch (or more like the way that workspaces behave in GTM) where different libraries/workspaces maintain their own sets of resources and histories, and at any given time you choose which library/workspace should be live on the site.  If you've selected a given library/workspace, then all the items in the list view rare filtered down and show you the current library contents rather than everything.

Assuming that's all correct, I can see why Launch would seem a bit frustrating, because it's organized around a different paradigm.  For those with a development background, it's not much of a strain to understand branching, and alternate versions of history, etc., but Launch was not designed to be used only be developers, so it takes a simpler approach and doesn't do branching and merging.

All items simply exist within the property, they are not specific to any given library.  The library is really just a group of individual changes that should be released together, and the set of changes moves through a workflow.  Once that library is published to production, the library mostly loses it's value as an organizing construct, and simply becomes part of the publish history.

We have been discussing the idea of an Working Library All the Time on and off for the last year or so.  Many of the ideas you've talked about here seem to fit better in that paradigm, but it would represent a significant shift in the way that resources are managed today - and would increase the complexity.  Perhaps that is where we end up going, but it's not on the near-term roadmap.

I will say that the next time we discuss Working Library All the Time, we'll come back to this post, because I think you've laid out your idea quite well.

[#9]

Thank you very much for your detailed explanations. It helps a lot to understand how Launch was designed and how to work with it more effectively. Regarding the Google approach I guess their idea was that the GTM user does not even need to know about branching and merging. It is more like a WYSIWIG approach. If you select a workspace everything you see, is just specific to the chosen workspace.

I can imagine that one can discuss many advantages and disadvantages when it comes to finding out what the best way is. I am looking forward to whats next. And I am happy if I can assist you with some ideas.