 All right, I'm gonna get started. So thank you everyone for coming. This is how to manage releases using git tags and semantic versioning. I'm Mike Miles, my pronouns are he, him. If you wanna follow along with these slides, I have annotated versions at this bit.ly link, which is bit.ly slash d-c-n-a-22-sem tag. The d-c-n-a are capitalized, and so is the s and the t. So before we dive into the topic a little more about myself, again, my name's Mike Miles. I'm from Boston, Massachusetts. I've been working with Drupal for 13, 14 years, something like that. I run the Boston Drupal Meetup currently. I've been doing that for about last seven years. I'm one of the organizers of New England Drupal Camp, which is happening mid-November. So if you wanna come out to New England in November, there's lots of beautiful leaves, so you should definitely come out to that camp. I work at MIT Sloan, the MIT School of Management as the Director of Web Development. So my team and I mainly were responsible for the mitsloan.mit.edu website, which is a Drupal 9 website, which we also manage with semantic releases, so I'm happy to talk about that in a little bit. As well as some other properties, we have some WordPress sites that we maintain as well. I'm also the host of a podcast called Developing Up, which is focused on the non-technal side of being a developer, so anything about having a career in development that's not about writing code is what we try to cover. I have to consider soon if I'm keeping this in or not, because it's been two years since I've done an episode, but the pandemic's winding down, so maybe now I can start doing it again. If you wanna know more about me all over the internet, MikeMiles86, Drupal.org, Drupal Slack, Twitter, LinkedIn, GitHub, et cetera, I think you can even go to MikeMiles86.com. I think I own that domain. I think it goes to my LinkedIn profile, but I don't remember. Anyways, let's set some ground rules here about what a release is. So in the context of this talk, when I'm talking about a release, I mean anytime you're pushing changes to your production environment, and what your production environment is is going to vary drastically across the group here. I'm gonna make a general assumption that most of us here work on Drupal-based websites, so production for us are production servers. But you could be a module maintainer, which then I guess production for you is Drupal.org. You could be a theme developer, you could have NPM packages, any sort of software. But anytime you're pushing a change, whether that change is a bug fix, a typo, re-architecture of your very popular WYSIWYG editor, that's a release. When you're pushing it up to production so it can be consumed by your production environment or your users. Oh, let's get to slide. And so the trouble with maintaining a project and having something that has a production version is that release management over time can become messy if you don't have any process in place that you follow regularly with you and your team doing your development. This can get messy in a number of ways. If you have discovered all of a sudden that you've had a vulnerability in your code base because of some piece of functionality, you wanna be able to quickly figure out how long ago was that change introduced? If you are building something that's being used publicly like say a Drupal module, if you don't have a reliable way for indicating the version of your module, it's going to make it hard for your users to understand can I adopt the latest version? What effects is it gonna have on my system? So what I'm gonna talk about today is first and foremost the basics of semantic versioning. Semantic versioning is a well-known numbering system used all throughout software to indicate the degree of changes from one version to the next. So we're gonna go into what that is. Then I'm gonna talk about some of the basics of using Git tags and the value of tagging commits in your Git repository. Again, I'm making a general assumption that I would say I would guess 99% of you are using some of the Git repository. Of course, if you're not, why would you come to a Git talk? But maybe you're interested. So we'll talk about what Git tags are, the two different types of Git tagging and how to use them. And then we're gonna take those topics, merge them together and talk about how you can use Git tags with semantic versioning to generate semantic Git releases in your Git repository to then keep track of the changes you push up to your production environment. And from there, I'm gonna share just a couple of tips for generating helpful release notes. There was a really great talk earlier today on documentation, which actually covered some of this, which I was excited to see. So I'll talk about how to write notes that are useful to the different audiences that you're gonna have to deliver them to. All right, semantic versioning. As I mentioned, it's a numbering system. It's a pretty straightforward one that's been around for decades. And it's used by everybody. And when I say everybody, I mean any piece of software you have likely has a semantic version number. So any of your operating systems that you're running, they have a three digit code for their current version. It's a semantic version number. All of popular browsers have semantic versions. So when you update to the latest Firefox, for example, you're gonna see the semantic version that you're using. Our favorite frameworks like Drupal, as you may well be aware, and you've heard like Drupal 3.4 just had a release or whatever the current release is. Like on, was it released Wednesdays? Is that what it is? So that's a semantic version number. And the tools we use get itself uses a semantic versioning for its number. Semantic versioning itself is versioned by semantic versioning for the guidelines, which is pretty interesting, which came first. So semantic versioning number, it's structured by three groups of numbers. You have the major, then the dot minor, then the dot patch number. And when these change, each time you change one of these numbers, it indicates a different degree of changes to your code base. So we'll start over with patches. Patch releases, which go from the version number 1.0.1 to 1.0.2, that's a patch release. And this indicates that there's been bug fixes or trivial updates, you know, you fix some hard code strings that were misspelled. In the case of actual Drupal project, usually patch releases also include security releases, depending on the changes. But it's anything you're changing in your code base that's not directly changing functionality or big sections of functionality or pieces of functionality in your code base. Minor updates going from version 1.0.2 to version 1.1.0. This indicates that you've introduced some sort of functionality change that is backwards compatible with the previous version. Example in Drupal could be the deprecation of an API in a version of Drupal 9. The API is still there, still can be used. It hasn't been removed but it's been deprecated, but that's a functionality change. And then major changes going from version 1.1.0 to version 2.0.0. This indicates that there are breaking backwards compatibility changes in your code base. You don't necessarily have backwards compatible issues, but usually that's what it indicates. So what we're all familiar with, I would say, you know, Drupal 7 to Drupal 8. It's not a very backwards compatible upgrade if you just upgrade your Drupal 8 code base. There's a lot of other things you have to do, which I think a lot of people have learned or to Drupal 9 at this point. So as you may have guessed, the frequency of when these changes, these updates happen vary. So the least likely one is a major update. Hopefully you don't have to rewrite your complete code base every time you're making a change. Minor updates happen more often than majors and then patches are what usually happen the most often because they're just the quick little fixes you have to do. The thing about semantic release numbers is they're set in stone. And what I mean by that is anytime you release a version of your code base using semantic versioning number, it's assumed that you're not gonna change the state of your code base at that point. That version means a specific thing. And now there's nothing technically preventing you, especially you can get from changing what that release number points to. However, it's just in practice, as soon as you release it to your production environment, you have to assume someone's using it. You have to assume that your production server is up and running and using it, that your end users have downloaded the latest version of your package already as soon as you release it. So you have to pay attention to what goes into it. A good example of this, if you are working say on four bug fixes for your code base and you released a patch update, but then you realize you forgot to commit the first, the fourth fix, well you can't just sneak it back into that release you just did, you would have to create a new patch release for that. So as a maintainer or someone who's a release manager, your job is to be responsible for double checking your version numbers before doing your release. So measure twice, cut once. What you should review is one in figuring out, well what number are you going to go with? What sort of changes are you introducing from your previous production release? So are you just doing a patch release or a minor release or a major release? And then making sure that that work that you're gonna include in it is added to that release and it's gonna be pushed out. All right, so that's semantic version number. Three groups of numbers, major.minor.patch. Patch means trivial changes, minor or functionality changes that are backwards compatible and major changes are usually non-backwards compatible functionality changes in general. So let's talk about git tags. A git tag is a way to add some sort of significance to a commit in your git repository. There are two types. The first is a lightweight tag. So lightweight tags are just basically they're pointers to a commit. I like to think of them as they're helpful notes so you don't have to remember a commit's hash number if you wanna switch to that commit. It's helpful for you to put a human readable name towards a commit so if you need to quickly jump back to it. Example, if you're working in the middle of development and you're building a big feature, you may start that feature with a commit and you're gonna tag that as like start a feature X and you can keep doing your work so you can roll back if you need to and you know you don't have to look through your git logs. The tag, how to create a tag, it might be a little hard to read the lights but from command line at least you say the command git tag whatever your tag name is. That can be whatever string you want. If you don't include a commit hash after that it's gonna go for your head commit so whatever the latest is but you can provide it a commit hash to apply that tag to so you can go back and back tag commits if you ever wanted to. So I can show this, let's see if I can show this. All right, so I have a sample repo here. It has just a read me in it. Is this big enough, you want me to make this text bigger? Bigger please, okay. Enhance, enhance, enhance, enhance, enhance. How's that? All right, clear, all right. So if I just do a git log on this repo my current commit in my read me is I started section five which I'll just show you here, not that one. Here we go, section five. So obviously what I'm gonna be making here are trivial changes but we can just imagine. So section five is my last commit here and if I wanted to now tag this commit which is my head main commit, oops. I would do git tag and then my tag name so I could say section five. And now, I'll just show you the git log. You can see here the top commit here. Head main, it says tag section dash five. So what that allows me to do, quick, if I start adding things here item one, item two. I commit these. Now you'll see that my head commit is different and if I wanted to go back to when I started section five now I can just do git checkout section five, my tag name. Right, so it rolls me back to that version. I hope I have to read me and it's just the start of that. So that's the easy way for me as a dev to go back to that. I'll go back to here, great. All right, so that's lightweight tags and I mention them because they're helpful tools in knowing how to do tagging but it's not the recommended way to use tags for marketing releases. What you wanna do for that are annotated tags. So annotated tags are different in terms of the fact that they are full objects in the get database. I'm not gonna explain the structure of the get database here, mainly because I don't know it. But I do know that they're full objects so they can be checked some, they have separate information than just the commit they're applied to. So we'll have who generated that tag when they generated the tag. Most importantly, they have tagging messages that you can attach to them, hence why they're called annotated. And they can be signed and verified using a new privacy guard. So you may see this for projects such as Composer. If you go to the Composer website to download it, you'll give you the command to download Composer and then it has a checksum that you can verify it against and that's basically what this does. So the way to generate an annotated tag, you say command line get tag then dash a and then your tag name. So that stands for you wanna create an annotated tag. Again, the tag name could be whatever you want. And then you could do dash m and provide an annotation message and you can do as many dash ms as you want so you can really get crazy with your annotations. And then optionally, you can add what commit to apply it to. If you don't include that, it will apply to your latest commit. So just to show the difference of what this looks like from a lightweight tag, let me do get show section five. I think that's the command. Yeah, so this was the tag I created before the lightweight tag. So it says tag section five and all it shows me is my commit information and the changes in that commit. But if I go to recreate this one, which obviously I haven't pushed it up to any production environment so I can change my tags. I don't have to worry about it. I'll do get tag and I'll delete section five. And now I'll, oh, I'd have to go back to the commit, don't I? Get log. See now I have to copy this hash. So if I do get tag dash a section five and then the commit hash, oh, I want a message though too. So I can add a message doing dash m, you know, started section five here. Then the commit hash, all right. So that'll create that. If I do get log, you'll see the tag is still applied to that commit where I started section five. It looks here, it looks the same as it did with lightweight tag. But if I do get show, what we see here now is a little more information. So it says tag section five at the top, then it says tagger and it says my name because I'm the one who did the tagging, what time tagging happened and the tag message, the annotation there, which is separate then from the committed information. So it creates a separate object that has a lot more information that's better for tracking purposes. So great, now what? Now if we were to take annotated tags instead of using just some random name, use a semantic version number, well then you have semantic releases because you can take that tag and since it's a state of your code base and do whatever you need to do for your process to push that version of your code up to your production environment or somehow mark that, that went out at a certain time. The benefits of using a semantic version number for your get tags and then relying on tagging for pushing out states of your code is that it signifies the important changes in your repository, because the semantic version number means a certain degree of changes in your code base. So you can say, this is version 232.3.0 and in it we rewrote how our email service works or something, right? It indicates that there was a big change in functionality. So you can quickly scan through your tags and know when you made significant changes or minor changes in your code base. That can help with tracking purposes and just history and knowledge. It communicates the degree of changes between two tags. So if you did a release last week and it was version 1.0.1 and you do a release this week and it was version 1.2.0, you know in between that week you changed some sort of functionality that was still backwards compatible. So again, you can quickly compare the differences from previous releases. And then it's just a straightforward way to track history of changes just again because of how the number quickly identifies the degree of changes. The benefits as well as I say it's supported by many Git interfaces is kind of a cop-out I think after reviewing this but it's because these Git interfaces like if you use Git Crackin, this is Git Crackin, screenshot Git Crackin, they show you your tags and if you're using semantic version numbers it makes it quick and easy for you to scan your tags and determine when things change. So in Git Crackin, the screenshot here on the bottom left, it has the tag panel and it lists out in this case it's a bunch of patch releases that were released because they're tagged. Or if you use GitHub or GitLab, you can view your tags again. This is from GitHub, this screenshot where we can see the same releases have gone out at different days. So for example, I'm gonna make a guess that where it says eight days ago version 2.7.4.2 went out and then eight days ago version 2.7.4.3 went out we probably forgot to include one of our bug fixes that we meant to release, so we had to do a quick another release, something like that. It's also supported by many automated tools. So if you use any sort of CI pipeline for doing your production deployments, having semantic version numbers on your Git tags makes that really helpful and easy to implement. Circle CI for example, again, I'm sorry for the brightness of this. You can define a workflow to be triggered on tags matching a regular expression. And so the semantic version numbers, number dot number dot number is very easy to track for. So this is what we do it and my team is our Circle CI deployment looks for tags matching semantic version numbers and that triggers the deploy to production build steps for us. You can do the same thing in BitBucket pipelines. You can trigger pipeline based off a tag structure. It's a little more basic, it just does blobs, but you can still, it's a simple structure to match for. And then I know Travis does this as well, where you can compare the value of the Travis tag to a regular expression. And I think some of the other tools out there that you may use for CI probably supports stuff like this as well. So to create a semantic release using Git tags, it's a one, two, three step process. One, you create an annotated tag. So you're gonna use semantic versioning for the tag name and provide an annotation. We'll talk about annotations in a moment. Number two, then you push that tag up to your remote repository. If you're using a hosted Git repository, then number three is insert your deployment steps here, which I know that could be step three to step 200 depending on your process. But in terms of using Git tags and semantic versioning for your release process, it's these three things and then you let deployment happen and it's triggered on a very specific structure as state of your code base. So if we take a look at creating semantic release tag using command line. Again, if you use a GUI like Git Kraken or even on GitHub, you can do this as well using their interface. You can generate these tags on a commit that way as well. But I like using command line. So it would be git tag dash A and then the semantic version number, which general practice for the tag name is to prefix it with lowercase v, which stands for the English word version. So version 2.7.45 and then a commit message, sorry, a annotation message, which you don't want to just be this, but you could start with the message release to then the version number 2.7.45. You want to do more than this though, which we'll get into in the next section. Then you do git push up to your remote with the tag number and then whatever your production deployment steps are from there. So if I show this here in that git repo, let's see, git status, great, we're clean, and git log, I think I have a commit here, right? Add items to section five. So let's say I complete section five. I have three, complete section five, yay. So now if that was a significant change in my code base and I want to push that out, let me look at my previous version. So I have these listed out here. Version section five, you'll see from my git tags doesn't fit the flow, but everything else does. So my last one was version 1.2.0. So let's say my next one is now going to be a minor release. So I'll do git tag-a version 1.3.0, message completed section five, which I think that matches as a minor release because I added new functionality. I added a new section. So if I do my git tag, you'll see that's listed down below and it's great to git show version 1.3.0. Then we see that, again, my tag information and then which commit it applies to that indicates that state of my code base. What does git log show right now? If I do git log, you'll see, so log just shows the commit that the tags apply to. So you see at the very top here, my main commit, my head commit, has the tag version 1.3.0. So that's why if you do git show and then the tag name or commit hash, it'll show you more detailed information about that. So that's where you get the tagger information. All righty, let's move on. So now what? Now we know we can use tags, annotated tags to mark full objects in our git database at a significant state of our code base and semantic versioning numbers to indicate the state of changes since the last release. Well, now we need release notes. Semantic version numbers are great for showing the degree of changes that have happened between two states of your code base, but they don't explain anything about the context about what changed. So this is why you want release notes to explain to your users, to yourself, to your team, here are actually the changes that happened. You wanna avoid just the bare minimum annotation of which I just did of release and then the release number 2.7.45 because again, that's just redundant information from the actual tag name. Now this is helpful to have it in there, but I wanna just have it be that. You can add as many dash M's as you want to your annotation and it'll do each one on a new line. So you can really get more verbose and list out the functionality changes that were included. In terms of what you should add and you may not wanna do all these just from command line I'll show you some other places to put them in a moment, but for patch releases, so going from version 1.0.1 to 1.0.2, you wanna at least list out the bugs that were fixed. You'll see that some projects could be issue numbers with a brief description or Giro tickets or whatever system you're using just to say like these are the bugs that are included, these are the trivial changes that were included. For minor releases, so version 1.0.2 to 1.1.0, you wanna include any patch release information but then any changes to the existing functionality. You wanna list that out as well. Importantly, any of the important usage details that change. For example, from Drupal, when an API becomes deprecated in Drupal, there's all this information that gets added about what services you should use instead, what other non-deprecated code you should use instead. So that would go into a minor release, things that would be helpful to understand the functionality that did change and then what about using that functionality do you need to change? And then for major releases, everything from minor and patch and then you wanna list out the functionality that's been removed, the functionality that's being added and most importantly, any upgrade steps that need to be followed or settings that need to change, environments that need to be updated. This is really important especially if you have a public project like an NPM package or a module and you want people to understand to upgrade to this new major version, version two of our module, make sure you have PHP 8.1, make sure you have these other modules and places, make sure you run this upgrade process, this migration, et cetera. You wanna list that there so people know what it will take to upgrade that version and they can make informed decisions for themselves. Now a note on private projects. So if you work on a project that's not like an open source project that you're pushing out to be publicly consumed maybe it's for your company's website, for a client's website or your own work. If you're the only person or your team's the only people who are going to look at these messages because you push out some sort of artifact and no one else has access to your repo, you could get away with not including all that detail as your release notes. At the very minimum, you could get a list of commit messages between releases and then include those as your release notes. Hopefully this only works if you and your team follow a pattern of using really verbose and helpful commit messages. Maybe you prefix them with your issue number or take a number, et cetera. But you could use get to compile these. So here's a command for get log using the pretty flag. Oh, my laptop's gonna fall. So you can say get log dash dash pretty format equal format colon modulus s which will get the commit message from a release or sorry from a commit. And then you can compare basically two commit hashes and it'll give you all the messages in between those two. So what that means you can do though, you can also take your previous release tag which points to a commit. And then if you're going to generate a new tag you could just say head or whatever commit it's gonna be applied to and you'll pull in the commit messages of all the commits between those two points. And I would add the dash dash no merges flag to this as well so you won't get the message that says merge branch x into main branch. Cause that's not helpful. And but you could take this in a leasing command line you could wrap it in a sub shell when you're generating your annotated tag in the message flag. And so you can have get do this for you. So I can show this just to show what it will do. I'm gonna get tag deletes version 1.3.0 that I created a moment ago. Again, I still haven't pushed it up to production so I'm okay to do that. And if I wanna do get tag annotated version 1.3.0 message and I really shouldn't just try to type that so I'm gonna copy it. No. All right, let's try to type it. Let's see. Get log pretty goes format modulus s. Come on, Mike, you can do it. Oh, version 1.2.0 dot dot or dot dot dot dot dot dot. Head no merges even though there are no merges let's throw it in there. I hit the double quote by accident. No, right now I can copy it. All right, oh come on now. All right, we're gonna move on cause I don't wanna, oh I'm still in a double quote. I don't know what I'm in now. Oh no, what did I do? All right, I need to unquote something. Control C. Control C. All right, thank you. I'm not trying that command again. Wait but I can fix it, I can fix it, I can fix it. And I could, I've deleted all this stuff a lot faster way too, but. All right, there we go. This needs to go here and this goes here. There we go. All right, woo. So get log looks the same. Version 1.3.0 is on the head. But if I do the information about it get show version 1.3.0. You'll see it pulled in the three commit messages from the three commits from the previous release. So for me, so that's helpful as a private project at the very least for your team because you can quickly pull those together. All right, now let's move on to extra credit. If you're gonna have a lot of changes or a public project and making them command line isn't gonna make sense, keep a changelog.txt or not read me in your repo. This is an example from symphonies changelog for version 5.3. So every time they did a release they would update their changelog and include that in the release and they still do that. So you can quickly list out your bugs here and keep track of it in your repository or publish a page of release notes. I think we're all familiar with going to Drupal and seeing what we need to do to upgrade to the latest release or for modules. A lot of projects do this. And so if you maintain something that's public facing you may wanna think about this especially for major releases where you may need to include a lot of steps just to help inform people. Or you can do this privately if you have like Confluence or something where you and your team or JIS or something if you wanna do that for your team. Just a place where you can put all this detail information and reference it later. You can also automate your tag generation. So if you're not sure, if you're still figuring out if it's a patch release or a minor release you could help from your marketplace. If you're on GitHub for example I know there's GitHub actions that if you apply them to your repo it will read your commit messages and look for keywords to determine what the next semantic version should be. So if you say like patch or minor or major in that commit. So everyone can be doing their own work if you work with a team and you commit it together and then the robots will figure out the next version for you. I think a lot of the CI environments out there they have scripts or tools to help you with this. Though if you have a very unique release process you create a bash script to automate the steps yourself. The bash script basically is like a wrapper for git commands that I showed. You could do that and pull together whatever information you need or make whatever updates you want. My team and I do this. So I created a script that we use and I've since open sourced it here at github.com slash mic miles 86 slash sem tag hyphen generator. And what this basically does for us and just use this as a guide if you want to or ignore it if you want to I'm not trying to sell anybody anything. But it basically wraps those git commands and you can tell it all these different options about hey I wanna do a minor release or a major release. I wanted to apply to this remote or this branch. I wanna just test it to see if anything will fail. Here's a commit message or the message I want. And if you leave that out it'll do the compiling of your commit messages for you like a demoed. So we use this because it's a lot helpful. It gets rid of a lot of the manual steps from typing because I have never screwed up typing. So it's helpful I think in that case. So for example, it makes it really quick and easy as long as the internet so works for me. Which I guess it does because my presentation's up here. I have the repo for that tool here. And I have, I have this little demo section in my readme. So look I demoed, I'm gonna demo this at Drupalcon 22. So I'll save this and I think I actually already committed that. Git log, now I added code bar first so I have to do this. Cool. Git status, great I have a change. Get commit, yay demoed at Drupalcon. Oh come on. All right. Semicolon, no single code, that's what it was. Okay, so now I have that commit. Git log, do I screw it up? All right, good it's there. And we'll tag this as a patch release. So now I can do, I can do sh tag release. And by default it will do a patch release for me. And if I leave everything off it will just take all the defaults which are described on the Git repo. But if I do this, it's gonna update it, it's gonna pull in the previous tag. I don't know, oh I have to push it up for a skip push origin. All right, let's try that again. It'll tell you errors if something's gonna break which is great, let's try it one more time. There, so I generated release 2.1.3 and it pushed it up to GitHub for me which is that's all my production steps for this. So now if we rewrote this, I have 13 tags, 2.1.3 and yay demo.drupalcon is the release message. It has today's date, it has the release number in it and then it has a list of commit messages. So that was really quick, right? For me I just had to know that command to type it. Just had to know a bit about the changes in my repo. So this saves my team and I a lot of work. We do daily releases almost and most of them are patch releases but when it's your turn to be the release manager, basically in the morning you're merging in commit or pull requests and then you're typing that command and it's generating for you. So takeaways from this. Symantec versioning is an industry standard for tracking releases and since we haven't talked about it in a little bit, just for refresher, patch releases are bug fixes or trivial changes going from version 1.0.0 to 1.0.1. Minor releases are backwards compatible changes to your functionality going from version 1.0.1 to 1.1.0. Major releases are backwards breaking changes in functionality going from version 1.1.0 to 2.0.0 for example. Git tags allow you to mark commits in your code base as having some sort of significance. So you can lightweight tags, use that as your development process so you can keep track of being able to quickly switch back to a previous version of your code base and then annotated tags to mark a more robust object about the current state of your code base. And then naming your annotated tags with Symantec versioning numbers is a simple way to generate Symantec releases or I guess a straightforward way and allows you and your team or your users to keep track of when things change and the degree of changes between releases. And then if you write helpful release notes they're gonna provide that additional context and information about what exactly did change and what people need to know to be able to use those changes. And I think also a takeaway from this as well is if you understand Symantec versioning number because it's used by everybody, working with Drupal use a lot of other third party code, use a lot of modules or themes or plugins and being able to see when their version numbers change and being informed about what that indicates to you can also help you with your project and keep it secure and make sure you're not gonna introduce something that then breaks your production. As well as it helps keep track of what your version should be. For example, I would recommend if you are updating to the next, if you go and say Drupal 9.3 to Drupal 9.4 it's a minor release in Drupal. For your project, you would may want to update your release number to a minor version when you include that Drupal core change because you've done a minor change from a major framework that your project uses so your project numbers should upgrade as well. I have resources for this talk. This presentation and annotated version with animated GIFs about the Git commands I did with no mistyping is available at this Bitly link, Bitly, DCNA 22, SEM tag, capitalization matters with Bitly so make sure the DCNA is capital and the S is capital and the T is capital. If you wanna know more details about semantic versioning itself the semantic versioning website semver.org has all the details about it and where it came from and how it's evolved and what they're thinking about for the future. This is a really long URL to read, I'm not gonna read it, but if you look at the Git handbook on Git basic tagging it's gonna give you more information about how tags work and where to use tags and other options you have with tagging. If you wanna help getting started with how to write effective change logs or release notes if you go to changelog.md they have some very helpful guidelines of how to get started and based on the focus of your project. And then if you wanna take a look at my tag generator for your own use or just inspiration on how you might do something similar it's that github.com such as Mike Miles 86 sem tag dash generator. With that I wanna thank you. It's been great. I'm so glad to be back with everybody and it's been great seeing everyone and talking with everybody. I didn't realize how much I missed it and how exhausted I'm gonna be after this week but it's been great. So thank you and thank you for coming. And I think there's some time for questions if you have any I'll help you happily repeat it into the microphone for you. Yes. Yeah, so the question was if you had a number of say patch releases like bug fixes and then a minor release you wanted to go out, is it better to combine them all into a minor release or do individual releases? I think it would depend on the timing. Like if you really need those bug fixes out now like their security improvements and you're not ready to do that other one yet do those now. But if they're ready at the same time you can combine them and they would make it a minor release say this minor release includes this minor change and these patch changes as well. There's no reason you have to keep them separate and do like a whole bunch of little releases. Thank you. Back there. Yeah, so the question was you know this makes sense for software and releases does it really make sense for like a Drupal website because it may just be all patch releases a lot. So we do have like me and my team manage Drupal website and I agree it can be harder. I've had discussions with people on this who feel either way. I think it's important because even if you're doing a bunch of patch releases for your code because there's the code base with your config changes especially for Drupal that you still want to be able to keep track of. Your end users like you're not going to show that version on your website unless maybe they're like healthcare organizations that have to do that. They follow a certain numbering system. I think it still makes sense just because to keep in the practice of it as well. And if you have someone new come to your team for them if they're used to those in that numbering system they can understand the history of your project as well. So I would say it makes sense to do. If you're the only sole developer and you're the only one who's going to see it you know no one's going to yell at you if you don't do it or anything. Yeah you have to make a judgment call and it can be hard with Drupal website. Like I wouldn't recommend like if you're making content changes that doesn't make any sense because the content's not stored with the code base. Like it's anytime you make changes with code base but so like if you update a view and the view change if you're just changing I don't know like you're using a table with zebra striping and you change the color of the zebra stripes that could be a patch release but if you're changing the view and you're adding whole new operation details or something like that could be a minor release. It depends on the degree of changes but so that's where it's you and your team need to talk about what have we really changed since last time we did a production and how should we market? Because there's gray area there and it takes a while to get used to. The question was did my team and I use change logs in our repo? No we don't. What we do is we're on GitHub so we mainly we have that script that compiles our release notes because we follow very strict commit message rules so it has like we use JIRA so it includes the JIRA number and stuff and so we just compile them here and we keep track of them here. We also have it releases are connected back to JIRA so every JIRA ticket also can tell us what release it was included in with the release number which is really cool so no we don't have a change log. Way in the back. Yeah the question is are there best practices for handling alpha, beta, et cetera? There probably are, I don't know them because originally when I put together this talk I thought about including that but the semantic versioning system says not to use those it should just be the three numbers. The one thing they do mention and I can show on this tags page is anything that's below version one is that usually indicates it's a development version so if you're in alpha or beta stage I would say at least from semantic versioning number you would still be at zero dot whatever or whatever and when you're ready to do your first production release release that's your version one to go out so there's probably are other guidelines on it that I don't know if, yes. Yeah so the question was they're working with a Drupal 7, a Drupal 9 upgrade and so Drupal 7 is version one, Drupal 9 is version two so in the work in between how do you mark those versions using semantic version number? I would say that's a good question. There's two options you could probably do in my recommendation would be you could use the zero, you could just stay, all right Drupal 9 is where we're gonna start that's what we'll consider our first version that we're moving up to it, right? It's a brand new thing on the website because you're gonna have to change the semantic version number anyways so you could do all the work up to there being zero dot whatever to give your team practice into doing that and then when you're ready to deploy Drupal 9 that commit is version one. The op-ed you could if just for historical purposes you could mark some version of Drupal 7 before you started the Drupal, to Drupal 9 upgrade you go back and just apply a tag to that say that's version one and then you don't have to back tag everything since then but you could start your tagging process there and when you're ready to go to Drupal 9 then you could mark it as version two. It is confusing and that's where it's a little variable based on what your team wants especially if it's not a very public facing project but you don't have to go back and back tag everything. Yeah, so yeah, but you can always go back and back tag and add tags if you want to. Any other questions over here, yes? Yeah, true or false? The question was true or false? Yeah, you don't have to so the comment was when you're still doing the production pieces before you do like a production release of the building pieces you don't have to tag everything and you don't have to. It's totally up to you you could just wait until you're ready for your first go live production and start like at version one dot zero. There's no reason why you have to go and do the past one if you're just gonna keep marking them for internal purposes. Well, we always use semantic version numbers just for our tagging purposes but we haven't had in a long time a project that isn't already in production so we haven't run into that thing where we're starting like a new project and up the time we release it to a production environment we don't tag it but I would recommend my team that we tag it though just so we follow the process. Yes? Yeah, you could add a lightweight tag to it if you wanted to so the question was if you wanted to mark something with alpha beta or whatnot you could do it as lightweight tag and there's nothing that's stopping you from marking the tag with that stuff in it like as an annotated tag it's just if you're relying on that's not gonna work I don't think that's gonna work for like composer or stuff like that so if you have a contributor project I think there's I don't know all the guidelines but there are guidelines for how to adjust those numbers to mark that and you'd have to look that up. All right, well if there's no other questions thank you again. Appreciate it.