Versioning in Paligo, it's really important, and welcome to this latest recording. We're gonna go through the general ideas and the details behind all the different versioning functionality we have in Paligo. And it's something that I'm sure you're going to use in your environments, whether you've got hardware, software, a combination of both. You have different versions internally, as you build to get to a final version. You have also maybe versions externally for your different customers. We're gonna see all the different ways of managing those versions so you can write your content in Paligo, whereby having maybe parallel versions until they're ready to go into the real version, etcetera, etcetera. Let's get on and see more details. As you may be familiar, this is the Paligo solar system, as we call it, all the different main pieces of functionality. So as you can see from the graphic, we're concentrating today on versioning but other things like authoring and reuse, translations collaboration, publishing, there's videos on them as well where you can get the same level of detail, whether you get it as a prospect, as a customer, and learn quickly about the main functionality. And as I always say in these recordings, It's a good idea rather than watch it from beginning to end. You've got Paligo in front of you. Watch a small section, maybe between the different slides. And then stop at the new slide and go over and reproduce what we do in the video to improve your Paligo muscle memory and it'll become even better at the product. Please don't watch this as a movie. Watch as a practical way to get to know the product much better. So as I said before, you've got lots of versioning inside your company for the different products. You might have releases every month, every three months. Or I've actually seen companies who have releases every day. A little bit scary, maybe. Sorry. If you're one of those, And it's really important that your content management also manages those versions. What you don't wanna have is every time you make a change, it becomes part of the live version even if the product for the documentation for that version hasn't been released yet, we need to have a way of managing. We've got versioning for our existing or live release. I mean, all these, let's call them draft releases, or releases that we're working towards. We have content for those in parallel. We must have a proper organized system. An organized system doesn't mean taking a Word file, save as, and having a completely new nonrelated, no reuse between those different version documents, having that of your methodology. That's the way I worked when I came into the industry thirty years ago. It's not a very good way to work now. We want to make sure we still reuse content between those different versions and basically spelling out the delta and defining when something is released as a piece of content to your customers and when it's not. We also want to be able to have a full audit trail. We want to know in a certain release, what was it? What was in there? What's changed? Maybe I want to go back to an old release and bring it forward again because I need it for a certain reason. There's so many versioning use cases, so many reasons for using versioning, it's really important to use it. And I would say from some of the history from some customers, it may be part of the system where they kind of leave it to the side. We'll we'll look it again in the future. I would strongly suggest that you're building your content strategy or maybe improving your strategy, improving your infrastructure, improving your reuse, it's really important to have a good look and good understanding of what we're talking about in this recording of all the versioning capabilities. It'll make your lives more efficient. It'll save a lot of hassle. You'll probably become writing things quicker by ensuring you're reusing the same content between the different versions. So butversion management in Paligo can maybe split into three logical groups. One is revision control. We can see what changes have been made between different versions, check-in and check out. Workflow and release management, we have different statuses. We have full releases. We can see what happens there. A third one we're not dealing with in this video, but it's really important is branching. There's a separate video specifically focusing on branching. The idea behind branching, why we need it. How to do it in Paligo, and through that we discuss lots of different types of use cases. I'd strongly recommend that you watch that video in addition to this one, so you cover the full versioning inside Paligo. So let's start getting stuck in into revision control. I have a quick look now at checking in and out documents, how that is done, comparing different versions together, but also what else can I do with these different revisions that I have in the system? So let's look at check in and check out. Really simple. In a lot of other systems, what you'd need to do is manually check something out, work on it and manually check it in. In Paligo, it's automatic. Let's open 'about our product'. And if you notice here, 'about' has a little tick and with the name alongside it, which is me saying that I've checked it out. And if I go and open another topic, You will see that's been checked out as well. So as you just saw, I opened about our product first. It had a tick. Then I opened 'a word from the owners'. So automatically 'about our product', the first topic, that was checked in. There's no tick there anymore. 'A word from the owners' was checked out, and the tick is there instead. I didn't do any manual work. And also if I, for example, go into 'getting started' now, and I'm opening it into a in a new tab, That is checked out as you can see. And if I were to close this one, It automatically checks it in. If I refresh this, you can see the 'getting started' is not checked out anymore. And in the same way here, if I now, for example, go and open to the topics folder, so it's automatically as well. Checking in 'a word from the owners'. It's got no tick anymore because it's not checked out anymore. A lot of the checking in and checking out is done automatically, but something to note is, for example, if you go away at the end of the day, you don't close the tab. Or you go on holiday, then it'll probably stay checked out, but as an admin, you can actually go in here. Let me actually check something. And here, I could actually go and check it in. Forceably, if you need to, obviously. Be careful because if someone has unsaved content, then that won't be saved. And if someone updates the content meanwhile, that could be a problem. So just make sure you think about the checking in, you have a policy inside your company for doing that. The next thing for revision control is let's have a look at revisions. You know, sometimes you want to go back, and you want to see what happened. Twenty years ago, in using a product I won't mention, I made a serious error, which is maybe what I do, in one of my documents, and I had to get the previous version of that file back. They had to go and restore the whole of yesterday's complete database for the whole company to find my single file. Well, that shouldn't be happening nowadays. How would I do that now? How will I find the revisions? So let's go and open one of our topics we've been working on. For example, 'welcome'. Click on the three dots, and I get to revisions. This shows me, and there could be many more than we can see here. This is a topic we haven't been working on for so long. Every single one of these different revisions. And if I click on the three dots. I could preview this version. So I could look at a previous version of the XML view to see what was in there. Maybe there's something specific that I put it in, did I not put it in? I'm able to revert back to this version. So in my case, I could have quickly reverted to that version from twenty four hours beforehand rather than having them restore the whole company database as we mentioned. I could create a new document based on this one as well, which is a possibility, and maybe download this full revision in its XML format for whatever reason you'd want it. And I can also compare versions. So the right hand side here, which I'll take my most recent one, I want to compare it, for example, say with with with this one. And you can also see the approximate changes between those different versions as well. Again, which version am I looking for? I only made a big change or made a small change, I can see. And if I do compare, I get a full XML compare, and you get color coded in different versions in this one. The green means it's been added. There's also different colors for edit and delete. So you can actually see what has been edited and deleted. Let's just try another one. We'll get some other colors. Give me let's try that one. Well, there we can see also what's been edited and what's been edited or then nothing's been deleted. So you really have full control, full history of the revisions in Paligo. This is for every type of document, whether it's publications, whether it's topics, informal topics, whatever you have that as well. I'll show you something else as well, which is important. Let me just add a quick sentence here, a new sentence. And I'll save. Not only do we keep revisions, of every document. We also keep provisions of every paragraph or every text fragment as we call them. Could be a title, it could be a caption. So if I click here on this paragraph, I go to the para menu up here, I go to text, and I go to show history. You can actually see there was an original, and I just changed it. I can go compare, and Paligo shows me, again, with a green background or a colored background, depending on what type of change it is, that was the difference between those two paragraphs. So you get a full audit trail of every change that you make, including at the paragraph level. That could be really, really interesting when you're trying to work out the different changes that happened, and also who made them? Now, we're moving on to workflow and release management. Really important to understand how this works, especially the statuses. Because if you use the statuses in the right way, you know where your content is. You can also search by status. I know what's in what's in translation, what's in work in progress, what's being released. It also way for me to manage the content, manage what the author's writing when they can write in it. Let's go and have a look at understanding the release statuses, actual release versions, and then what do we do if we want to start work after release? We're in the pubs folder, and you can see here the publication, the statuses is here. If I click, we can see five different release statuses. Let's list them and explain them. Work in progress means you're working on it. You can do all the things you want with the content. In review, that means it's been sent to review, but I can still work on it. There's nothing blocking an author going in and to make changes. In translation means it's been sent for translation. In this case, as we discuss, in also the the branching recording, the translation recording, is that an author isn't able to go and make changes. Reason being, if you send something for translation, and then you update the source, when the translation comes back, it's not fully aligned with the source. So you can't edit something in translation. Should you want to do is that use case, then you'd use branching. Translation review is an option where reviewers can actually review the different languages but at different translations in Paligo, and release will be talking about it more very soon. That's when it's fully released, and we have a full audit trail for that. So if we want to change the status and sometimes they don't automatically, by the way, when we do the collaboration side, if I send something for review, you can set it in the default settings where it'll automatically change the status to in review as well, but sometimes they're done manually. I just wanna do an experiment with you now, and you'll see in the topics folder, everything is also in a work in progress. And I could go to each topic individually, and I could just say change it to in review. What I'm going to do here is go back to pubs. If you notice at the bottom here, it says change status for all included components. In our case, I'm on thepublication. It'ss included components of all the topics. So if I change the release status, it's gonna change it for everything. All the topics inside that publication. Watch. I'm going to click on review. So Paligo is changing the status, not just for the publication, but all the topics inside the publication, and it's creating snapshots for every single topic, which I'll show you in a second when we talk about release. So there you can see that's in review, the publication. When I click on topics, anything that's directly inside, the publication has also been set to review. Reuse piece of content would need to be updated separately because maybe they're being managed in a different way. They could be part of multiple other publications. So that's using the release statuses. And we can also search for them as we'll see in a future video on search, and it gives a way to organize and manage our content. So next thing we might want to do, and this really should be part of the process. We wanna set something to released. When would I set something to release? Well, the obvious time would be the release of the product. But you might also wanna do it during drafts if I wanna have like a full audit trial, a full, you know, snapshot of what happened at a certain point in time when I sent an official draft over, I could also use release there. So it's really up to you the word is released, but it's up to you when you use these different statuses. When you play with them and understand them, you might start to get more of a general idea of when to do that. So how do I set to release? Let me just click on release. But I get an extra window we didn't see before. I can put a comment for this version. So I can go back and historically see. So for example, let's say this was version... So say this was version 2.1.1. Whatever information you want, you can put in here longer, shorter, maybe a quick summary of the main differences between them, whatever you want to do. We also have this, make this a minor or major release. I'm gonna show you in a second what that means. I'm gonna leave that. This is a major release. Nothing to do with music and click okay. So similar to before, Paligo is changing the release status of the publication and the subtopics and making snapshots of each one, you should know that if something was checked out, Paligo would ask you if you wanna check it in or not before continuing to do this process. So you can choose yourselves. Maybe I want to stop at this point or it's okay to carry on doing the full release. So we can see that as released and let's go back into topics again. See they have all been set to released as well. We're gonna click on this left icon, which provides all sorts of information I'd have seen before, where it's related to everything else, because you see that in the metadata, but I'm clicking on versions. And you can see there's this version that I just created 2.0.0. So we set a major and minor release. The number two, the number on the far left, that's the major. If I would have made a minor release, this would have been called 1.1. So the number in the middle, the second number, that's the minor release. The third number is actually done automatically by Paligo when you change things. If I would send this to review, probably be called 2.0.1. But that you don't you don't affect the number, yourself. Sometimes we're asked, can you change this number over here? And the answer is no. These are internal Paligo versioning numbers. If you want to put your comments in, that's where you put them in the comment, you can edit comment. Gets that same window that we saw before. That's where you put your versioning and your details in. So other things to note here. I can restore a version. What this would do, this will restore the version, this snapshot. As it was, in a completely different folder. So even if the actual publication has changed and the reuse content, everything has changed, it doesn't matter. This is a standalone version. That I could I could put into a separate folder for later use. A use case. I didn't think that we'd have to use the release from eight months ago again. But we have a certain customer who needs a specific change for this release, and we've provided them separate documentation just for them. This may be where you'd use a snapshot. So you go back in time to complete publication, make a change, and it's for them to use, for you to use for your customers. I could also remove the version if I wanted. This icon here can also download the file, and it downloads it as XML, what we call a Paligo export format that you could always import again later. And if we have a look at all the separate topics in here, you'll actually notice that if we go into the versioning, that Paligo has created a separate snapshot of every single topic as well. So not just a snapshot of the whole publication. Every topic has its own snapshot. So again, should you want to restore a specific topic in that wholepublication; you're able to. So you've got a full audit trail of every release. As I said before, whether it's a full release, whether it's a partial release, you decide. But a full audit trial of both the publication and and the topics in there, and you could do the same thing with the admonitions, just do it manually and your informal topics of how you want to reuse things. And now a fun extra, as I call them. Up to now we've been speaking about versioning, internally managing those versions. What about and this is not relevant for everybody, whether maybe you have a product with multiple versions, multiple pieces of your hardware, multiple versions of your software. How can you allow the customers to select those different versions? So Paligo contains an out of the box type of functionality. It's more on the publishing side I just wanted to give you a feel and very quickly show you how you do that. And you could watch the video all about how we change layouts for HTML5 to set that up in detail. I'm just gonna run you through it just to really give you an idea of what you can do. Let's just take a look of this example for Moogsoft, one of our customers, of what I'm talking about. If I put my mouse over 'select version', you'll actually see they have different versions here. And if if I click one, it'll open that different version instead. So if you have versions one, two, and three, for example, you'd create this list. Let me just very, very quickly show you how to create this list. And go to my Paligo, go to layout. Again, not really getting into detail of how you manage layouts. I've created a layout called Steve HTML5. I'm going to open it in a new tab. If we go to the help center theme options, and go down a little bit. you'll see something called versions for version drop down. And there's a simple syntax here of the text colon than what you want to call it and then the url to put it in. So, like, you can see, they they're just they're essentially links. So you could link to most likely different folders on your server or different files, whatever on your server, different paths, or it could even be external. That creates that version drop down as you saw. If you wanna see details about that down in the help, please look in that help publishing multiple versions of content and there a little bit more detail repeating what I just said. And then you'll have something like this with the drop down in that Moog software. Try it yourselves really quite easy. Okay. Everybody is now an absolute expert in versioning, or at least you watched the hold of the video, and well done. Please go back if you haven't and try it yourself. As I say, please try these things on your own, play with them. Go to the branching video like we mentioned as well. And I'm sure it'll be ultra successful in managing versions. Reach out to us if you have any questions or alignment questions with your use case. We'll be more than happy to help you succeed with your versioning everything else inside Paligo.