The Laravel Podcast

Matt Stauffer:
Welcome back to the Laravel Podcast, Season Four. Today, I'm talking to Jason McCreary, the creator of Laravel Shift, about upgrading Laravel. Stay tuned.

Matt Stauffer:
All right. Welcome back to the Laravel Podcast, Season Four, where every single episode is about a particular topic, and we are down to two more episodes for this season. Today, I'm joined by my friend, Jason McCreary, who is... I mean, I don't even know what things to introduce you as, but the most reputable one, and the first time you started making a name in the Laravel community was the creator of Laravel Shift. So, I won't do any more introductions. Well, I guess we're talking about upgrading your Laravel applications, keeping them up-to-date. I won't do any more introductions. Could you just say hi to the people, and when you meet people, how do you actually talk about what you do?

Jason McCreary:
Yeah. Hello everyone. Jason McCreary. Go by Jay Mac in the community. You probably know me as that. How do I introduce myself? It's really funny. I've found in the past few years, like, I don't introduce myself very well.

Matt Stauffer:
That's my answer. Not very well.

Jason McCreary:
I just say my name and I guess I just don't talk about me a lot. Then the nice thing is, of course, nowadays, at Laravel conferences, I don't really have to say anything because I've spoken in a few, or whatever, so I don't... I'm kind of out of practice, is the point. I'm not exactly sure how to say... I mean, I've been a developer or a programmer for 20 plus years now, PHP... and most of that time, I mean, I was writing PHP back in the CGI modules days.

Matt Stauffer:
Yeah. All right.

Jason McCreary:
Yeah. So, Laravel, probably about six or seven years now. So, since 4.2, for sure, and then that big leap to five is where I was like, okay, this upgrading stuff's for the birds. Let's do something better-

Matt Stauffer:
Let's do something.

Jason McCreary:
... because I've always been a scripter a PHP scripter at heart. So, yeah, got into that, got in the community, started speaking and do more from that platform now, which is nice.

Matt Stauffer:
Yeah. Very cool, and we'll make sure... we'll link to your Twitter and base code, and all those different things, all in the show notes, so people can follow you in every way they want. Of course, at the end I also ask them how they can pay you money, so that'll be helpful too.

Jason McCreary:
Yeah, I'm sure we'll stumble on some of the other things-

Matt Stauffer:
Yeah, quite helpful.

Jason McCreary:
... to even out that introduction, so, yeah.

Matt Stauffer:
For sure. Okay. So, the topic today is just the word Upgrading, and it's a combination of the process of upgrading your Laravel app, and then also just keeping things up to date in general, whether that's the app itself or the ecosystem around it, or whatever. I don't even know how to ask you to do this. I'm very curious to hear your answer to this, but how do you explain that concept to a five-year-old?

Jason McCreary:
To a five-year-old?

Matt Stauffer:
Yeah. I ask everybody that and I'm like, I'm very curious. I don't know how this one works for this one, but I want to hear what you say anyway.

Jason McCreary:
Yeah. I'd be like sometimes stuff gets old and dirty, and you need to clean it up, and this happens every now and then, and it's best to do it when you notice it's gets dirty or you notice it gets old, and that way everything stays clean and fresh.

Matt Stauffer:
I love it. Clean and fresh. That's good. So, if someone who was a JavaScript programmer or a PHP programmer, or something, who didn't know Laravel, how would you give them a quick introduction to what the upgrade... Not even just the process, but what does the world of upgrading look like in Laravel?

Jason McCreary:
Yeah. It's actually pretty good, to be honest, and again, not trying to give Shift or anything any kind of credit. It's pretty good on its own. The upgrade guide from Laravel is excellent. It's a nice place, definitely, to get started, but sometimes it's thorough enough that that's maybe all you need for most apps, you know?

Matt Stauffer:
Yeah. So, let's say I didn't know what all those things were, right? How often do I need to upgrade and how big are the upgrades, and all that kind of stuff? How do I learn how to upgrade?

Jason McCreary:
Yeah. Well again, I would definitely point people to the docs. Check out the upgrade guide. Laravel's got a good one, of course, but yeah, Laravel previously was pretty fast moving. I think people would consider every six months, there was a release. I think part of that, people weren't maybe up to date on... or knowledgeable of that release cycle, to your point. That confused people. Laravel also had a move to SIM versioning. So, semantic versioning, which that was a little confusing for people, even though the release cycle was exactly the same. I think just the major version numbers changed. WordPress did that a few years back, same thing. It's 3.3 and 3.4, and 3.5, and each one was actually a pretty major release, but depending on what versioning scheme you're used to, that can be confusing. Maybe it's a major, maybe it's a minor. Who knows?

Matt Stauffer:
Yeah. If I'm new to the Laravel world and I'm picking up an existing Laravel app, can you give me a trick to identify where in the history of Laravel's process... Because there's different pre-SemVer, SemVer, and then also the new thing you just announced. So, how do I know where I am in that process? What's the quick rule?

Jason McCreary:
Yeah, definitely. The simplest thing to do, of course, is just run artisan--version, and that's going to spit out the framework version, and from there you can line that up with something in the docs, but the easiest thing to do is really to look at the first two versions. If you're on the five series, then you're still the old versioning system where that second number is going to be a major release. So, 5.8, for example, or 5.7. Those are two major releases, but once you get six and higher, then it's really this 6.X or 7.X, and that second number doesn't really matter as much anymore. It's more about the main version, but yeah, running artisan--versions give you a real quick way. You don't have to go digging around composer or anything like that. You can just see where you are and then line that up with the docs.

Matt Stauffer:
Yeah, and that's the main trick that you said, is that, for me, if you're before Laravel six, then every dot releases a major version, and if you're at Laravel six and later, every not dot is the major version. The major versions go... starting at 5.1, 5.2, 5.3, and then we get a six, that's six, seven, eight, and that's a lot of, I think, what's overwhelmed some people, especially who are newer to the community, is not knowing that these... it's moving just... The move from 5.7 to 5.8 is the same size as the move from seven to eight, but it didn't feel like that for folks who were used to the old system.

Jason McCreary:
No, absolutely. If I were like... it was really funny because in the very beginning of all that, and still actually every now and then, I'll get a support email and it's like, where's the Shift for 8.20? If I were real slimy, I could just release something every week and pay five bucks, but that's the thing though. It's like, again, it's confusing even now, after a few years of that new whole number, that first number.

Jason McCreary:
Then, of course, we had talked about this a few weeks back, but laravelversions.com is a good way to cleanly jump out and match that version up with, are you still supported or not? That's another resource to check, because there's really only two versions at a time that are supported, LTS, long-term support, and then the latest stable release. I like to throw that 'stable' in there because sometimes people think, oh, it's the latest release, so it's cutting edge... it's bleeding edge. But it's not. That's the latest, released stable version of the framework. We're not pointing at Dev Master or anything.

Matt Stauffer:
Yeah. I was going to say, dev-master... if you really want to be on unstable, it would be Dev Master, and not where the release is.

Jason McCreary:
Exactly.

Matt Stauffer:
But there could be three stable versions sometimes, right? Because as of... until March 1st of this year, we had six, seven and eight all stable.

Jason McCreary:
You're right.

Matt Stauffer:
But only for a short amount of time, and now it's six and eight again, right?

Jason McCreary:
Yeah. Under the old release, six months... you did have a six month grace period where that second to last release was still supportive, kind of-

Matt Stauffer:
Still running.

Jason McCreary:
... but it really is the... yeah. It really doesn't get a lot of love, even if it is 'supported'.

Matt Stauffer:
Yeah, and that was... So, for a time, when we switched to semantic versioning, the releases were coming out every six months, and then just recently, Taylor gave us an announcement. Can you kind talk a little bit about that?

Jason McCreary:
Yeah. So, they're moving to annual releases. They used to release in March and September, every six months, but now the March release is going away for, for now anyways. So, this year, there'll only be one release, and that'll be early September. Normally coincides with the layer cons in the summer, so everybody can show off the new features and get some buzz going, and prepare everyone for all the new hotness.

Matt Stauffer:
Yeah. Cool. So, we haven't talked about Shift and I want to actually get there. Normally, I'd wait until the end to talk about your product, but I think that enough casual references have come up to Shift and I actually maybe want to move to not just Laravel, but some other things. Can you just, really quick, tell us what Shift is and then tell us the story about how it came about?

Jason McCreary:
Sure. Shift is an automated service for upgrading Laravel applications. Instead of doing all these manual things that we're talking about, figuring out the version you're on, figuring out all the changes, scrolling through the upgrade guide and then determining which ones apply to you, which ones don't, all the things that maybe aren't listed in there... forget all that. Forget all that manual stuff. Just make it automated. It's just a few bucks. The latest version is always $9. I like to keep it just a super no-brainer, simple.

Jason McCreary:
If you think about that, even if it just saves you an hour, which is normally the estimated upgrade time, even by the Laravel team, that's $9 an hour. I really hope that that makes economic sense for you, right? So, yeah, it makes that whole process upgraded. It gives you a nice PR, that's almost a customized upgrade guide in a way. It tells you, okay, this does apply to you. Make sure you double check these things. As far as the genesis, it was probably at a PHP conference... I forget... I think it's 2015. It's been around five years, but Taylor was there and I was giving a talk on moving from 4.2 to 5.0, and I think Taylor was in the back or something.

Jason McCreary:
I went up and introduced myself afterwards and just was chatting, and in that talk, I'd kind of said, "Okay, well here's some shell scripts that I have. Move the directories and all the..." again, the tedious junk that was part of the 4.2 to 5.0 major change. I asked him, "Hey, do you know if there's any tools out there like this, a CLI tool?" Because I used to write a bunch of kick PHP and they would release a CLI tool way back in the early days that was like a shell script that just did the high level stuff, at least. Right? Moving files and renaming things, and stuff like that. And he was like, "No, but I'd use it," and I was like, "Okay."

Matt Stauffer:
Okay. That's a sign.

Jason McCreary:
So, I think at that hack-a-thon at that conference... there was a hack-a-thon that night or something, I sat at his table and just learned more about the upcoming 5.1 release of what's going to change. So, I got ahead of the curve there and-

Matt Stauffer:
Nice.

Jason McCreary:
... made that be the first Shift ever. I think I started selling it for $2.

Matt Stauffer:
Yeah, it was just stupid cheap back then.

Jason McCreary:
It was so fun.

Matt Stauffer:
And the funny thing is, the Shifts back then, whether using Shift or not, was a much bigger haul to upgrade Laravel and those other things.

Jason McCreary:
It is. Yeah. Yeah, those are really huge.

Matt Stauffer:
And you don't still have that Shift around, do you?

Jason McCreary:
Which one? You mean like the 5.1 Shifts?

Matt Stauffer:
Do you still have the 5.1 Shift?

Jason McCreary:
Oh, yeah. Shifts goes all the way back to 5.0, from 4.2 to 5.0.

Matt Stauffer:
Got it.

Jason McCreary:
So, every major...

Matt Stauffer:
It's possible we've used it. I mean, well, of course we used it back then, but it's possible we've used it recently, because I just tasked one of our... one of the tech guys to rescue a couple of old applications that were sitting in the dust.

Jason McCreary:
I think that's something that people may not realize. I think, again, we get caught up in all the new hotness and everything. The community is so large, that there's... you would be surprised. I think a lot of people would be surprised how many old apps are still floating out there, right?

Matt Stauffer:
Couldn't agree more. Yup.

Jason McCreary:
And it's not fair to really even call them old apps because actually, if this app is still ‘alive', it's because it was successful. Right?

Matt Stauffer:
Yeah. It's probably still being used today.

Jason McCreary:
It's because it's still being used. Exactly, and it finally has reached this critical crustiness that we've got to go back and clean it up. We've got to make it fresh and clean again.

Matt Stauffer:
Yeah. I mean, a lot of our clients are in those situations where they come to us and they're saying, "Hey, we need help upgrading. Then we also need help rethinking the architecture, and training up our team in the idiomatic ways of Laravel," or something. So, I'm always a big fan when folks you, or even PHP package authors are willing to say, "Hey, you know what? Not everybody's on the latest, greatest hotness," because it's just not really true. Maybe everybody who you talk to on Twitter is, but that's a very small percentage of the actual user base of Laravel.

Jason McCreary:
Yeah. I think it's a blessing, of course, that there are older apps for me being Shift, but it's also a little bit of a curse, I think, sometimes, too, because it just doesn't keep upgrading like, again, this... the new hotness thing, right? It's just this old crusty thing you have to do, like, "Go clean your room." It's not very fun. It just doesn't... there's recognition of Shift at this point, but it's been a very long slow grind because it's not like the new JavaScript framework or CSS framework, or whatever. Right. It's just this routine maintenance. It's very mundane.

Matt Stauffer:
Right, but it's both. It's mundane, but it's also... everybody's got to do it, right?

Jason McCreary:
Yeah. I then got teased with Jacob Benet, last layer con, that I was like the garbage man. It's like an essential service, but nobody really cares.

Matt Stauffer:
But everybody notices when the garbage man doesn't show up, right?

Jason McCreary:
Yeah exactly. You notice when that's an old app but you might not notice when it's fresh and clean.

Matt Stauffer:
Nice. Okay, so that's what Shift is. So, you provide that service at laraavelshift.com. We've talked a little bit about upgrading Laravel Shifts. Before we talk about upgrading things other than Laravel, you've given some notes in some of your talks about some common things that you notice that make upgrading easier-

Jason McCreary:
Sure.

Matt Stauffer:
... and that's whether or not somebody is using Laravel Shift, because it could also make it easier... Like, let's assume that everybody here is not using Laravel Shift right now. What are some tips for building Laravel apps that will be easier to upgrade in the future?

Jason McCreary:
Absolutely. Yeah. My whole goal of all this is to have it be so people are running the latest version of the framework, just because, again, going back to WordPress or Magento, or some of these other communities I've seen inside of PHP over the years, it just creates such a drag in that community when you have these outdated versions and unsupported versions, and this huge plugin community that's just unwieldy. I mean, not to pick on WordPress, but just, their success became a curse at some point, and I would hate to see that happen at for Laravel. Like, this massive growth suddenly becomes a drag, right? So, I don't care if you use Shift or not. I want to make sure that you're able to upgrade your application. So, to that point, the main thing I would say is, is absolutely do your best to follow conventions.

Jason McCreary:
If you're not seeing it in the docs, if you're not seeing it in some of the popular resources that are out there, or even built into the framework, it's not an artisan command... If you're trying to develop something beyond that, really justify that reason. I'm not saying don't do it. I'm just saying, literally talk out loud for a second and say, I'm going to make this special design pattern that's not in the framework anywhere, or can't be generated with artisan because X, Y, Z. And sometimes there's a reason, but I think nine times out of 10... probably 10 times out of 10... I'm going to say, you're going to go back... you're going to come back to that and be annoyed someday when you do upgrade to Laravel 9, 10, 11, 12, and suddenly, oh gosh, that was a terrible idea.

Matt Stauffer:
Or your whole team says, "Sorry, we can't upgrade because we're still stuck using this custom thing, or whatever, that can't be upgraded or whatever.

Jason McCreary:
Exactly. Even worse than-

Matt Stauffer:
We'll have to re-order it all from scratch.

Jason McCreary:
Yeah. Even worse. Yeah. If you just keep dragging that... that's the whole point. It's going to create a drag on you. So, really try to see the examples on the docs. Look at the framework itself, look at its patterns, models, traits, concerns, things like facades. Embrace... they feel foreign at first, right? And then maybe if you're a hardcore, real technical design pattern type of developer, you might not even like some of those patterns, but try to embrace them. They really end up feeling and being easier to work with later.

Matt Stauffer:
Yeah. I'd agree with that in the patterns, and I also agree with that on the tools themselves. I mean, the number one reason why I see people have trouble upgrading outside of probably outdated packaged dependencies and low versions of PHP is that somebody decided that they didn't want to use Laravel scheduler or Laravel's database engine, or whatever, which of course, I'm always a big... person out here saying, hey, look, one of the great things about Laravel is you don't have to use its built-in tools. And like you just said, however, when you choose not to, you're also introducing some costs in the future. So, you've got to balance those, and some people will do it just because they're like, "Well, I think I can do it better." And what do you end up with? Well, it's never done better, but that's just my opinion. But furthermore-

Jason McCreary:
Sure.

Matt Stauffer:
... you now have built this entire framework, fragile framework dancing around things, that now has to be kept alive as you're doing an upgrade, versus just, oh, well, the system's responsible for upgrading itself. All you've got to do is compose or update, or whatever.

Jason McCreary:
Yeah. I mean, everything has a cost of maintenance, and elaborating on that, even packages. If you go and reach for a package... again, wonderful package community in Laravel... just like the WordPress plugins. I mean, there's something for everything, if you spend a few minutes searching around. But again, just keep in mind, if you use that, even though that particular package will be upgraded or maybe supported in the future, it could also be abandoned. It could also have its own upgrade steps. So, again, you really have to consider every decision... the potential weight of it as a maintenance cost, because it is. Every line of code you write is a maintenance cost.

Matt Stauffer:
I love that. That's the quote right there. Every line of code you write is a maintenance cost, but the framework... the lines of code that come with the framework aren't maintenance costs for you, right?

Jason McCreary:
Yeah. Mostly not. Yeah.

Matt Stauffer:
Yeah, mostly. Yeah. Same with the packages. The package code technically isn't, but you still have to be dealing with the upgrade flow.

Jason McCreary:
Yeah.

Matt Stauffer:
Any other... oh, go ahead.

Jason McCreary:
I was going to say, then you get a little meta. The decision is the cost then to use it, but yeah, you're right. The code is for free in those things.

Matt Stauffer:
Yeah. So, are there any other tips that you would give to people to make it easy on themselves down the road, as they're writing their code now?

Jason McCreary:
Specific for code is a little tough. Obviously, base code, but more specifically base Laravel does a good job of highlighting several tips and practices in there, for even just how to craft individual bits of code, but also introducing you to the things in the framework. That's the other thing. You might not know patterns that Laravel is doing necessarily, and even though the docs and everything are great, I mean, you do have to stumble through them a bit. You can read them a book, but whoever finishes an entire book? I don't know. So-

Matt Stauffer:
Not me, unfortunately.

Jason McCreary:
You skip around, maybe, a little bit. Who knows? But, especially on the web. So, again, it's one of those things where that tries to introduce a lot of line-by-line things, or feature by feature. So, yeah, I don't have anything specific beyond that. I mean, I think the conventions are huge. Leverage them as much as possible, everything from the code that can be provided, the code that can be generated, down to the table names and even just the structure of the application. It's just not worth making your own design.

Matt Stauffer:
Special snowflake.

Jason McCreary:
I know we all to believe that, but I think the older you get, you realize, "I'm not special at all."

Matt Stauffer:
Yup. Okay. Those are really good notes on that one. So, this question may end up being the exact same thing, and in which case, if you have no answers, we'll just move on, but I want to ask it from the opposite side. Is there anything you see making people really get caught up? What's the most common thing that you see people running into with problems, whether it's shifting on their own or through Laravel Shift? Is it the same answer or is there anything different about looking at it that way?

Jason McCreary:
I think if you look at what gets people caught up, maybe outside of the conventions, like in the thick of it, I do think people struggle with dependencies a lot. It can be quite annoying when you go to upgrade, especially if you want to be the early adopter, like that first week in September when Laravel nice drops day of, you're upgrading. It's tough because it's not like some other ecosystems, maybe iOS, for example. When they launch in their big Apple event, they've got all the big gamers up there already showing you all the cool new features and how their apps are already ready, but because we haven't seen Laravel 9, unless you're developing in it's master, it's a little bit of a chicken and egg problem. So, these package authors, they're just not ready that first day. So, even though, again, of course, I say, upgrade, upgrade, upgrade, you don't necessarily have to be the first one out of the gate. I typically wait a week or two.

Matt Stauffer:
That was going to be one of my questions. How long do you wait to upgrade yours?

Jason McCreary:
Yeah. I think I see people run into that, specifically being the package development, just some things not being ready. Now, I've tried to... with Laravel 8, Jess Archer and I actually worked on a little feature, "Can I upgrade yet?" So it's, "Can I upgrade laravel.com?" and basically, you dump in your dependencies and it gives you a checkbox if it's ready or not.

Matt Stauffer:
That's freaking magic. He showed it to me and I was just like, wow, this is cool how this works. So, I love that.

Jason McCreary:
Well, what's really fun about it underneath is there's a little collective intelligence there. So, when you drop that in, if we're not tracking it, it says untracked. Then we will actually begin not only to track it, but if they don't have Laravel 9 support, for example, in September we'll issue that package author a PR-

Matt Stauffer:
Oh, cool.

Jason McCreary:
... that does... at least bumps their versions, so they're compatible to start giving them, and then in the PR comments, we'll let people know... because sometimes those sit. You'll go, "Well, gosh, there's an open PR for Laravel 8 Sport, but they haven't merged it yet. "Yeah. Well, we'll leave in the comments, "Hey, if this is pending review, here's what you can put in your composer file to-

Matt Stauffer:
Very cool.

Jason McCreary:
... use this and try it out.

Matt Stauffer:
To use this PR.

Jason McCreary:
And let them know this works.

Matt Stauffer:
Yeah, or doesn't work. Sometimes, just bumping-

Jason McCreary:
Or doesn't work. Yeah.

Matt Stauffer:
... a version, you've got to do more than that. Yeah. That's really cool. I like that a lot.

Jason McCreary:
We've been trying to solve that problem as well. So, to the point of learning what are the problems when you go to upgrade? I think the dependencies are the biggest thing. Then the next most annoying thing are the configuration files, and this is definitely a hill that I'll die on, but it's one of those things where... I've bounced this off Taylor a few times, but I wish there was just an overriding config file instead of like, "Here's all the config files. Keep track of them." I think there's a lot of people that are just like, "Oh, well, just delete what you don't use," but then it's a little unclear when you go to upgrade, well, did I remove that because I wanted to remove it?

Jason McCreary:
Did I remove it because it got deleted? Did it used to be in there? It's so many questions, so they're very hard to manage. Shift has done a really good job of trying to do crazy three-way merges and get it all back together again, but I wish it was a little more... for those that are familiar with Tailwind, I wish it was a little more like themed out extends. I wish it was a bit more like that. I remember talking to Adam about that when he was releasing version one, and we had a big chat on configuration files and trying to convert them. I was like, you definitely don't want people like... Trust me, you don't want people messing with these, like trying to give them as much...

Matt Stauffer:
Yeah, and that's what Tailwind was originally. Originally, you published the entire Tailwind config file and then later they're like, "No, you're just going to publish your changes to it."

Jason McCreary:
Yeah, just change what you want, and the things that are core that you want, here's a helpful little method that gets them out. I think it's clearly kind of... I don't know... a better direction, in my opinion. Yeah.

Matt Stauffer:
Yeah. I agree in terms of the... it's funny because at times, I think you've said pretty strong statements about not using configs and I've pushed back a little bit on it, but what I do agree with, like, if you start getting a sense for how git-diffs work and what breaks in git-diffs and what doesn't break in git-diffs, I think in those moments, you can start saying, "Well, let me apply that to the changes I make to my config files." So, even if you do still make your changes, your config files say, what can I do? How can I make the changes to this config file in a way that's going to minimize the cost, if I have to diff it, or have Shift diff it against a new version of the config file in the future?

Jason McCreary:
Absolutely.

Matt Stauffer:
So, for me, that's like, keep my changes relegated to a single easily identified block between one thing and another thing, or at the end or whatever, right? That's often the easiest thing. So, rather than deleting the things you don't need or coming up with a whole bunch of weird new names or whatever, literally just add a new section of what you need, call it today. Like, the config/services. I'm always adding new services-

Jason McCreary:
Sure.

Matt Stauffer:
... but I add them at the end, and I'm trying ... I'm not reformatting the whole thing from tabs to spaces, or whatever. I'm trying to keep it as same as it was before, except for those little extension.

Jason McCreary:
Exactly. Yeah. It's like you own those files, clearly. They're in your repo and they're generated, but at the same time, you kind of don't because really, what I've seen to the point of upgrading, I've seen companies come to me and, "Gosh, we upgraded this. Help us out." It's been one line of configuration that they missed. Some new option or some rename, and... or even something as... unfortunately, as simple as... in production, they just didn't clear their config cash or something. But I've seen people get choked on that and just days on end, like...

Matt Stauffer:
That's rough.

Jason McCreary:
You know? So it's tough.

Matt Stauffer:
Yeah. Just can't figure out where this problem is coming from.

Jason McCreary:
Nowadays, that's one of the first things I look at when someone's saying, "Oh, we've been messing with this. We've been messing with this and it's not working." I'm like, yeah. I just literally go diff all the configs against the defaults, and if there's ever an option missing, it's pretty funny. It ends up being that. So, those can be quite tricky. You may not think you need to upgrade them, but then you'll do a composer update one day and even get a minor version, and you're like suddenly something doesn't work because the expectation was, is that, that key existed in the config file.

Matt Stauffer:
Yeah. When I have gotten really stuck on upgrading with config files, I will take my config file and diff it against whatever the stock config file for the version I was upgrading from, figure out what I changed, then grab the version, stock version from the new version, paste it in and then just paste my changes in again on top of it. It's a pain when I have to do that, but that saves me so much pain if I'm in one of those situations where I just can't get it merged healthily.

Jason McCreary:
Yeah. Yeah, I have a whole blog post on, yeah, just some thoughts on how to manage the config files, but yeah, just like you said, try to be minimal with your changes. Again, leveraging patterns inside Laravel, create an ENV. Create an ENV that you can configure separately from the config file. That way it's easy, because most of the options in Laravel give you ENV files... or, sorry, ENV variables by default. So, just use those. Don't change the second argument. You know what I mean?

Matt Stauffer:
Yeah exactly.

Jason McCreary:
Just use the ENV.

Matt Stauffer:
Yeah, and you can also create your own config files. So, if you find yourself slamming a whole bunch of things in a could fix/app or something that, it might be better to add something that's config/my learning system, or whatever you're configuring, and that thing won't have any problem reconciling in the future, because that's your file entirely.

Jason McCreary:
It's all custom, yeah. Like in Shift, I have a Shift config file, so... and then sometimes there's a genetic one. I just call it settings. Settings dot whatever.

Matt Stauffer:
Yeah. Yeah, that's good. Okay. Those are some really great tips about upgrading Laravel, whether or not you're using Shifts and writing code that's going to be easily upgradable in the future. So, I wanted to talk a little bit about practices around upgrading, and you already covered one of them, which is how often should you upgrade and when do you upgrade? So, you said upgrade early and often, but you also mentioned that usually wait a couple of weeks after the release. Are there any other patterns or processes that you use or you would recommend other people use, just to set their brains in the right space around upgrading? How long they should set aside or what things they should do at the same time, or anything else like that?

Jason McCreary:
I think as far as things that you should do at the same time, I mean, definitely check PHP versions. Those are moving pretty quick these days as well. I don't think Laravel is as pushy about the PHP version as maybe they could be. I know some package authors are, for example, the Spatie packages. They push pretty hard to the latest version sometimes. So, I think taking the opportunity to look at your whole stack... can I upgrade my SQL, can... and I'm not saying do it all at once, but maybe, to the other question that was in there, dedicate yourself maybe a couple of days early one week, the early part of a week... The first day, upgrade Laravel. Push it out there, let it sit, let it simmer, let it marinate. Make sure there's no craziness.

Jason McCreary:
Don't go changing your whole stack at once. That's definitely not what I'm saying, but if that looks good, then maybe the next Monday or something, go ahead and bump the PHP version. Right? If you've got a highly trafficked application, then you can do it day, day, day, or whatever, but if you don't get a lot of traffic, or you're just one person, like me... I might do that each week. I'll bump to Laravel 9. Maybe late September, early October, I'll go to PHP 8.1, or maybe it's 8.2 by then. Who knows? And maybe there's a new MySQL release. I like taking those opportunities to rebuild the stack.

Matt Stauffer:
You can also check your NPM dependencies as well. You can update them, check your node version, your NPM version. You can start locking those things in your package.jason. We've gotten to the point where one person on the project recently was using NPM. I think it was six, and one person was using eight or something. One of the newer ones, NPM seven or eight, introduces a thing where when you run install, it reformats your package.jason in a certain way. Then you get these conflicts. because one person's ... so, it's helped all these dependencies, your composer update, your NPM dependencies, your at MySQL. I love the... these are all things to be eyeing. One of the number one reasons to think about that is to minimize the cost of doing it each time, which is one of the things that you're really big about, right? I want it to be as easy as possible for you to upgrade. It's funny because Shift actually embodies that idea for us by literally charging more money for the older ones. The actual dollar cost of doing older Shifts, like-

Jason McCreary:
Sure.

Matt Stauffer:
... 5.1 to 5.2 is higher, but it's also... let's say you're not using Shift or whatever. It's just the bigger the upgrade you're doing and the longer ago it was, the harder you're going to find it to do, and the more you're going to have moved out of the way of what the regular, I guess, the flow would be. If you're expecting that there's going to be these upgrades on a regular basis, you just keep up with it and you're making little changes over and over, rather than one massive change every once in a while.

Jason McCreary:
Yeah, and that's actually one of the reasons, and probably another thing that I might push on. I don't think I push on too many things, but I think, as far as the upgrades go, the config files would definitely be one of them. I'm a stickler on those, admittedly. The other thing I'll be pushy about as LTS is a total trap, to that point. I just...

Matt Stauffer:
I think you've written blog posts about that, right?

Jason McCreary:
Yeah.

Matt Stauffer:
At least one.

Jason McCreary:
That's title for sure.

Matt Stauffer:
Yeah, that's what I thought.

Jason McCreary:
It's gotten some appropriate opposite feedback from it and that's fine. I totally get it from an enterprise standpoint. Right? You kind of... that vision of, okay, we're going to use this and it's going to be supported for three years. We'll never have to change, and I get it because there's a big upfront cost to develop whatever you're developing. You want that security, yada-yada, but to what we were just saying a second ago, you're totally immediately buying into years' worth of technical debt, and now that Laravel is going to just one release per year, think of how far behind you're going to be on features, right? It's not just going to be six months or a year and a half anymore. Now it might be two years, it might be three years. If they stick with the every third one as an LTS, you're talking almost four years of technical debt by the time you decide to make an upgrade. In a nutshell, that's why I'm not a huge fan of LTS. You're committing yourself to old features, old code and debt.

Matt Stauffer:
And more expensive upgrades, because you're not going to end the LTS period, then upgrade up one. You're going to end the LTS period and upgrade up to the next LTS, which means you're going to have to try to jump three versions at a time, which means-

Jason McCreary:
Sure.

Matt Stauffer:
... that's going to be a lot more difficult, so, yeah, totally agreed. I mean, the general mantra, the idea is to upgrade as often as possible, upgrade not quite as early as possible. Give it a little bit of breathing room for the early adopters, and also for the package maintainers, like you mentioned. Like at Titan, we try really hard to make sure all our packages are compatible on day one, but we don't always get there.

Jason McCreary:
Exactly.

Matt Stauffer:
So, give the package maintainers a little bit of a breath and then upgrade in a couple of weeks. There's also, usually, at least four or five patch releases on day one. They'll put it out and then someone will, will notice a bug, and it will get fixed instantly. So, you don't have to roll through those.

Jason McCreary:
Yeah. The framework's excellent, as far as... If you don't have many package dependencies, you're just a core stock Laravel app, that's awesome. I think it's rare, but that'd be awesome. You'd check all the Jmax boxes, if that was somehow true, but yeah, even then, upgrading the very first day is always going to have a little headaches, but I do want to give credit to the Laravel team. They absolutely crush it with getting that ready to go, being responsive. Those first few days of merging and past releases, and dropping those... tagging those immediately.

Matt Stauffer:
Yeah. So, wrapping up a little bit, is there anything that we haven't got a chance to talk about with regard to upgrading, or really anything else that's in your wheelhouse that you want to make sure we cover?

Jason McCreary:
No. I mean, the new parent brain doesn't give me a lot of time for free thought anymore. So, I didn't really think ahead on any extra special things, but yeah, I just... Again, I think the big thing for me is... and the whole motivation for me behind Shift is, again, just to make sure everybody's running a later version, so you can focus on the cool stuff and programming, right? Upgrading your stuff is not a cool thing, right? Maybe if you get a brand new computer and you're putting all your new apps on it, maybe that's fun, right? But going through a crusty old application and making sure it's on the latest version, because you got to hit some deadline or do some features... not fun.

Jason McCreary:
So, I've tried to give you an outlet to offload that for just a couple bucks while you go enjoy the rest of your life, but, again, whether you use Shift or not, I really hope that the time part of that, like maybe getting into a different area... value your time, right? You've got more important things to do. Even if it's not programming, you've got more important things to do with life. You don't want to be up at-

Matt Stauffer:
Yes, exactly.

Jason McCreary:
... midnight hacking together composer issues. I think developers, sometimes, we get excited on a positive. We get excited and we're like, "Oh, I could do that in 15 minutes," and then it's like, I wish you could see a time lapse when people say that, with a clock behind them, like a basketball game, like the little shot clock in the corner. It's like the code clock in the bottom. It's like four hours later, you know?

Matt Stauffer:
Yep. Yeah, multiply it by 10 and add 20% and you've still got another... you still weren't right.

Jason McCreary:
Yeah, yeah. So, it's interesting.

Matt Stauffer:
So, I end... before we get to the point where I ask you for all your social handles and how people can pay you money, there's one thing I ask at the end. It's unique per person. I had seven different things I wanted to ask you, and I did end up deciding to ask you a question around woodworking. I know you do some woodworking. I knew that there's two people I know who do super legit woodworking, You and Jesse Shoot, where you're like, "Oh yeah, I'm taking this down to the mill. It's going to sit there for nine months while they do this, that, and the other," and I'm just like, "What are you talking about? I buy stuff at Home Depot and barely know what to do with it."

Jason McCreary:
Sure.

Matt Stauffer:
So, my biggest question is just, how did you get into it? What actually drew you into this level of knowledge about woodworking?

Jason McCreary:
I think, well, first of all, if I'm even close to being in the category of Jessie, I totally appreciate that, because he's got some-

Matt Stauffer:
He's next level, right?

Jason McCreary:
... crazy stuff going on. So, that's awesome. Yeah, talk about pairing or something. I would love to wood-pair with that guy, whatever they call it.

Matt Stauffer:
Yes. No kidding.

Jason McCreary:
So, that'd be cool. But yeah, I think I've always enjoyed the outlet of doing things with my hands. I think that's one of my taglines on some network is 'build things with my hands'. That's the references, is... because programming is such a mind game, right? It's a puzzle you've got to lock in. You're plugged in and you're just really working through all those iterations in your head, and it never ends, right? When I wake up in the morning, there's going to be support emails from Shift and I've got a task list to do. Then tomorrow, I'm going to have to upgrade NPM and it's... so, the whole point of all this, it just never ends, but I think I always loved being able to just make something and sit, and in a way, like, not necessarily even appreciate it, but just, it's done.

Matt Stauffer:
It's done, yes.

Jason McCreary:
The doneness.

Matt Stauffer:
Yeah. Yep. And you know when it's done, right? There's a clearly defined doneness with a-

Jason McCreary:
Exactly.

Matt Stauffer:
... table.

Jason McCreary:
Yeah, yeah. You don't... yeah. When you're done with the table, you're eating on it. That's it. Period. There's no more work. Maybe you wipe it off every now and then.

Matt Stauffer:
You don't have to upgrade the legs or something. Yeah, exactly.

Jason McCreary:
Yeah. So, in high school... I probably started messing with woodworking, probably in high school, but I think more interesting to me in high school was mechanics. I would drop the engine on my car and place the clutch, and do... I just loved... I was a big gear head. I loved doing stuff that. And again, a very simple thing. As soon as you put the new clutch in, you could shift better, right? Shift your car, not your Laravel app. But it's one of those things where, I think, the woodworking I liked because it allowed you to be a bit more meticulous, kind of like programming. You can be as refined as you want to be. You can reach for that fancy pattern and use all the latest hotness, Alpine JS and all the great stuff and it's... Or, you can just be like, whatever. Vanilla, Java... I'm using jQuery and CakePHP.

Matt Stauffer:
Whatever gets this thing working and out of my head, as fast as possible and then move on. Yeah.

Jason McCreary:
So, I appreciate that there's that level of it, too. I can get out the hand plane and actually get that down by hand, and you end up getting so tired. You've got to do more tomorrow. You're done today. Or, you can do the electric one and be like, okay, let's go. Bring out the powers tools. So, I appreciate, I think, the parallels to that, right?

Matt Stauffer:
Yeah. That's cool.

Jason McCreary:
And it's fun. I think when I'm laughed out of the programming community a couple of years from now, for being so old or whatever, like, "Old man Jay Mac, whatever man," yeah, I'll probably go do woodworking.

Matt Stauffer:
Yeah. So, there's a follow up question on this one-

Jason McCreary:
Sure.

Matt Stauffer:
... which is...

Jason McCreary:
Yeah, please. I love questions.

Matt Stauffer:
Again, I'm getting into woodworking so I could talk your ears off, but I won't because I try to keep it to one. What's your absolute favorite tool that you own for woodworking?

Jason McCreary:
Absolute favorite tool for woodworking, ooh. I'm going to have to think about this for a second.

Matt Stauffer:
Or one that you want, if it's one you don't have yet.

Jason McCreary:
I don't think this would need to be used a lot, but I think it's my favorite tool. It would be... I have a nine inch sander. Technically, it's a grinder. This is really more for metal. This is a pretty metal raw tool, right? But I bought a bunch of sanding disks for it, because again, like we talked about, I actually work with some pretty raw-

Matt Stauffer:
Hard surfaces.

Jason McCreary:
... lumber, like legit log. So, if I'm wanting to craft something out of it, I almost need to just grind that thing down.

Matt Stauffer:
Oh, okay. Got it.

Jason McCreary:
It's such a messy, manual tool, and if you don't respect it, it could kill you. So, it's pretty... I think the aspect of all those different dynamics at play makes it really, really fun. And when you get done, it looks like someone threw pancake mix on you, because you're just-

Matt Stauffer:
You're just totally covered.

Jason McCreary:
... the raw dust is everywhere.

Matt Stauffer:
I love that.

Jason McCreary:
It's just, I love the grit of it right? Then, of course-

Matt Stauffer:
That's awesome.

Jason McCreary:
... when you're done too, you've got this nice polished whatever thing I was working on. I'm down to the pretty wood now. I've got off all the saw marks and the dust, and stuff from 10 months of sitting out in the kiln and now I'm seeing the refined wood and you can run your hand on it. It's baby butt smooth and...

Matt Stauffer:
Nice.

Jason McCreary:
So, it's a fun tool.

Matt Stauffer:
That's very cool Well, two of my favorites...

Jason McCreary:
And it's mean.

Matt Stauffer:
Yeah. Two of my favorites are the sander, which for some weird reason, but I like sanding the same way I like pressure washing-

Jason McCreary:
Sure.

Matt Stauffer:
... which is just like, I'm just sitting there doing... But then, on the other side is the chainsaw. So, I feel like yours is halfway between both of mine. I'm using-

Jason McCreary:
Sure.

Matt Stauffer:
... these little wimpy chain sander, and then this terrifying chainsaw, and you're like, "Look, let's just put them together in one tool." That's going to be mine.

Jason McCreary:
Yeah. This grinder, if you've got the right belt on it, yeah. It could easily be just a horizontal chainsaw. Yeah, it's nuts. I do like the chainsaw, but yeah, I don't use it enough, I guess. That's probably the right word.

Matt Stauffer:
I live in a little forest, so I get to use it all the time.

Jason McCreary:
That's awesome. I'm jealous.

Matt Stauffer:
Yeah. Oh, Jason Beggs has been offering to let me come up to his property, which is very close to me, and just cut as many trees down as I want. He's like, "I have too many trees. If you ever find yourself in Georgia, then definitely..."

Jason McCreary:
No, he... yeah. He messaged me today and was asking about kiln and mill-ware, which I thought was great. I was like, yes, not a programming question. I love this.

Matt Stauffer:
I love it.

Jason McCreary:
He was probably, "Okay, dude. I got my answer. Leave me alone now."

Matt Stauffer:
No, he's... he'll chat your ear off about that, too. Okay, so don't go about woodworking forever.

Jason McCreary:
Sure, sure, sure.

Matt Stauffer:
How do people follow you? How do they pay you money? I make that as a joke with lots of people, but you actually do have a service. So, how do people follow you? And of course, I'll put all the blog posts and stuff in the show notes, but what do you want them to check out?

Jason McCreary:
Yeah. So, I'm @gonedark on Twitter. That's probably where I'm most active, as far as the programming topics and whatnot. So, if you're on there, you'll get links to all the fun stuff. Then, of course, we've been talking about Shift, and just to point out, there are a lot of free Shifts, too. If you've still got your models on namespace, things like that, there's all sorts of little helpful Shifts that are free. If you just want to toe into the water, there's the Laravel Linter you can check out for free. Then, of course, if you're running an old unsupported version of Laravel at this point, which is everything right now instead of six and eight, so it's a very narrow window... so, if you're running anything other than Laravel 6 or Laravel 8, definitely get upgraded, be it Shift or not.

Matt Stauffer:
Yeah. Love it. So, links to your podcasts and all your other things will be in the show notes and that's it for today. Thank you so much for the service you provide the community, both the paid service through Shifts, but also the ways that Shift is being a part of helping us all do better here, including the free stuff that you do, and also, you said the pull requests to packages. That's freaking brilliant. But also just for the way you teach and share, and everything like that. Thank you so much for joining us on the show.

Jason McCreary:
Oh yeah. Thank you.

Matt Stauffer:
All right. See y'all next time.