Hey everyone, welcome back to the show. Today we have Jason McCreary, aka JMac, aka Gonedark, who's the creator of Laravel Shift, many awesome pull requests to Laravel and much more. Welcome to the show, Jason. Thank you. Yes. I guess start off with, why don't we have three names? You couldn't settle on one, you're just like, "I'm going to have all these." Jason McCreary, I guess, is what my parents gave me. Jaymak, I've mentioned it, it's a LaraCon talk.
I don't know why, but every job I've ever had, there has been at least one other Jason. I've been on a smaller team where there were four Jason's. So by that point in time, everybody was, you do high school, you do last name, "Hey McCreary, hey McCreary." But that didn't even work. There was another one, Jason Meredith was his name. There was a Jason McKey that I worked with one time. So eventually it was like, "Okay, you're just Jason and you're Jaymak." So that's where Jaymak came from.
Gone Dark was just, I think when I first joined Twitter, I was watching Jack Bauer, 24. Remember the old, we're Zoomers, so you probably remember the old TV series of Jack Bauer. I always thought it was hilarious when Jack Bauer was like, "I'm gonna go dark." That was when he was super spy out of communication. And I just thought that was a stupid, ironical name to have for Twitter, massively public tweets at the time. I thought that was funny. It is, that's good.
Yeah, it's funny, because we used to show him my age when 24 came out, it was like a thing, everybody, we would go to my buddy's house and we would watch it. It's like, "What's gonna happen in the 13th hour?" People don't understand the excitement of an old show like that, that was really pre-internet and DVR and all this stuff, and no binging. I mean, you had to wait a week and talk to your friends and guess what was gonna be on the next show.
Some of the excitement's gone because of that, I think. Yes, totally agree. I think Lost was one of the first shows that was pretty cool, where it was just like deep internet archives of, that was probably the best balance of week to week, but then also internet. Now it's all ruined. You can just watch every episode in an hour. Yeah, that's been our consumption now. You find a series and you just binge it and then you're like, "Oh, what are we gonna do now?" And it's like, "Oh."
Okay, that's done. You can't even appreciate it almost. It's just like it's done now. For sure. All right, so let's jump into Laravel 12, which is coming out, as of this recording, it's coming out in about two weeks. So by the time we publish, it'll be right around the time. I have been following along a little bit. You have been actually deep into it because you've been doing live streams on Laravel 12 stuff. So what specifically have you been working on with it?
A lot of the live streams actually were more ideas. I always have these things that I wanna see be in the framework. And then of course you get busy the whole year. And then they announce, "Laravel 12's coming two weeks." And you're like, "Oh crap, I wanted to see if I could add this." And they're normally bigger concepts that like, yeah, you couldn't throw out in a minor release. Maybe it's a breaking change. Maybe it's a convention change. Maybe it's a default value that gets changed.
So those are more what the live streams the last few weeks have been. It's just like, can these tiny little things get into Laravel 12 as potentially breaking changes? Cause you get once a year to try to get something that's breaking. And we all know, and I'm sure we'll talk about, Taylor's now of the stance, he hates breaking changes, no breaking changes. So some of them got in, some of them didn't. Some of them were, they're tiny little paper cuts. But yeah, that's just me as a Laravel user.
That's kind of unrelated to shift. It's just me, like as someone who's used Laravel for 10 years, here's some small little power user things that I would love to readdress. I would love to have more attention, right? Yes, which that sort of brings me to, you're very good at the paper cuts because the current Laravel release that came out yesterday had all these new little date, relative date methods. And I know they got declined before, but for me, I just love little stuff like this.
Like it's easy to talk about it, it's fun. You know, you can refactor all this stuff. So how did that come about? You just were like, I'm gonna do this again and it's gonna go through this stuff. Yeah, I was working on that side project with JT and I wrote it. I wrote, like a lot of the times these paper cuts, like again, as someone who's used Laravel for 10 years, sometimes you make assumptions of like, well, this has to exist, right?
Like you don't necessarily have the autocomplete or something, but you're kind of like, there's so many beautiful, human, expressive, chained methods in Laravel that a lot of times you're just like, hey, I wonder if where past exists on Query Builder, right? And I had done that two or three times in this other side project and it wasn't there. And I was like, I feel like this was there. And then I stumbled on that PR that it got declined, I guess two or three years ago now.
And I was like, I'm just gonna resubmit this in its current state and see if it gets in. Cause honestly, sometimes it just gets in, right? Like everybody's got a new mindset. There's more to the framework now. There's more of these kinds of helpful methods. Taylor's in a different place. Maybe he now sees a need, right? So there's just so many factors. And it's funny that you said that you liked it. Cause yeah, it's just, I find lately sometimes these things are met.
As the community grows, you get more opinions, right? That's just how the world works. And I just, sometimes these PRs, like they're just met with some thumbs downy stuff lately. And I'm just kind of like, I don't know, that doesn't feel the way past, you know, sometimes they just get in right away. They're not even whatever. And then other times you'll get 50 thumbs ups and it gets closed. And then other times you'll get 10 thumbs down and it gets merged. So it's just funny is all, right?
Yeah. And like you said, I assume a lot of it just comes down to what the reviewer, the end reviewer thinks that day, you know, like if it's Taylor or if it's somebody else, it's just like, you just need to catch them on that right moment. I think it's always Taylor. I mean, he says that anyway. I mean, there are other people that might chime in from the team, but he, I think is still to this day, like merges every PR. Like it's a point of pride for him.
You know, the framework is always going to be his baby. Yeah. I think, yeah, from everything I've heard too, I do agree with that. But I was going to say, Laervel itself has actually been merging more of those. You know, we've got that number helper. I think CodeWithCaen put in. There's been all these little helpers in this last, I feel like in the last year that that's came about. And again, I think they're super useful and super fun to talk about, but yeah. I kind of mentioned that to, yeah.
I mentioned that to Taylor, like, especially, you know, we were talking about these date things cause he was kind of, you know, oh yeah, I dig it. I don't know why we didn't merge this before kind of thing. And like, it was, it's one of those things where, you know, I think the framework is so large now that you're going to have, you're going to have to have aliases for things like naming so subjective.
If you want to appeal to the broadest audience, you can't just be stark about, okay, well, this is the technical name that we're going to use. Like you need to allow like where not, and you know, missing versus exists or both. I mean, so there's going to be a lot of aliases for methods that maybe one person likes missing and one person likes not exists, right? Like it's just, again, it's the way the world is, right? Yeah, yeah.
It kind of reminds me of Tailwind CSS with the way they spell gray and then I spell it the opposite way. And it's like, I always have to go in and put an alias in cause I can't speak the other way. Yeah, I think at some point they said, no, it's just gray with an A, I think, I don't know. But I remember gray with the E for a little while. Yeah. Yeah, you could choose that as a framework, but I'm glad that Laravel doesn't, right?
I think if you want to appeal to the most, I mean, don't do it willy nilly on everything, but once you do it once, you kind of have to accept that you're going to get PRs for a bunch of aliases and.
Yeah. Well, so, you know, as you're submitting pull requests and looking through the framework and stuff like that, I know you're talking about, you know, fixing little paper cuts and things, with Taylor saying that Laravel 12 is not going to be a breaking change or, I want to say that's what he said, right? There's going to be no breaking changes in 12. No breaking changes. It's the claim. The claim, yes. I was going to say, so does, how's that going to work going forward?
Is this just going to be like a one-off release this way, or do you think they're going to keep striving to not have breaking changes? I do think it's a trend for Taylor and team. You know, I know Nuno has been a big fan of things like Rust, and I know there are things of these other languages, you know, there are traits of them that, you know, they don't have necessarily big huge releases, or they don't have breaking changes. You just kind of toggle on features or you opt into features.
So there is maybe something there for the future. At the same time, I mean, we have to be a little bit realistic in the fact that like, no breaking changes, there's some nuance to breaking change, no break, that statement, there's some nuance, right? We all know this, like, just because there are no breaking changes doesn't mean there are no changes.
So it's not like you can just truly go into your new app and say, or your LayerVille 11 app and say, Composer update, and it just runs LayerVille 12. Like you, at the minimum, you got to go in, you got to bump your dependencies in your Composer JSON file, you got to review some things to make sure there aren't some new pieces that have to come into the core files or config, I mean, config files are always changing.
You know, every minor release, there's a new ENV variable or a new line of code or a new option inside of a config file. So, you know, if you upgraded the LayerVille 11 last March, you have a year worth, you have 52 releases, minor releases of LayerVille that have happened since then. And there's a lot, as we just talked about, there's a lot of stuff in each one of those things. So, you know, what direction is the framework heading as far as major releases and breaking changes?
I don't know, that might be a trend, but at the same time, the parallel that maybe we're getting at here is, you know, what is shift going to do, right? And there's always stuff to change. There's always code that changes. I think we all know it's never just as simple as running Composer update. It's maybe it is once or twice, but it's not by LayerVille 13.14. At some point, you're going to pay down those kind of shortcuts that you took along the way.
And so shift is always going to be there to kind of make sure that your app truly looks and feels like LayerVille 12, right? Like there's a huge difference between LayerVille 10 and LayerVille 11, right? That was a huge release. I think it gets underplayed because the docs kind of say, don't worry about changing your structure, but there's a lot there between a LayerVille, if you go look at a LayerVille 10 app and you look at a LayerVille 11 app, completely different, you know?
The way in which you do almost everything is completely different. The way you register middleware, different. The way, you know, you configure your app or bootstrap your application, different. The way you put things in service providers, different. There are no more kernels, you know, so much changed in LayerVille 11. And again, I think because of the upgrade guide, not everybody moved to that structure.
So if nothing else, the LayerVille 12 shift would make sure that you are following, you know, everyone's gonna slowly move to that structure. We all, again, we all kind of know and know this deep down. And who knows if that structure ever, that older structure ever gets, you know, unsupported. You know, this happens, right?
Yeah, yeah, the, you know, speaking of LayerVille shift, basically for like LayerVille news website, I always run it through shift and it's just, I mean, like you said, I was going back to Laravel 10 versus Laravel 11. I went through the upgrade guide and I was like, "Eh, this is not too bad." But I was like, "I'm gonna do it anyway because it's like, I don't want to, you know, spend any time on this really."
Yeah. And then it was like, "Boom!" It's like, "Boom, here's like 70 commits to fix all this stuff and change it around." I was like, "This is perfect." Like, it was so good to go through that and just have it, you know, not even have to think twice because you've already done the hard work. Like, "Why am I gonna waste this time of my life when you're doing it, we could send you some money and it's just done." Yeah, I mean, that's the thing, right?
Like, it's always, you could always, the statements of, you know, hopefully you can just run Composer Update and be on Laravel 12. That's always going to be a possibility. That always has been a possibility. I think where shift's value really, really comes and where I hope that over the last 10 years I've kind of earned the reputation is that shift again, its goal is that your application looks and feels like LayerVille 12.
It's not just running LayerVille 12, it actually looks like LayerVille 12. Your example code, your code matches the examples from the documentation. The conventions are adopted. You know, you are truly running a LayerVille 12 application. In that regard, shift has always gone far beyond the upgrade guide, very much so for 11, and you know, as you noted. And it'll continue to do that.
So I hope that even if there were truly no breaking changes like there's still going to be a value add that shift can offer. Honestly, I'm kind of excited because it allows me to focus on more of those conventional code changes that, you know, with 11, I got to move your files or I got to do a lot of work there and I don't want to make the PR too noisy.
So maybe I didn't do some code refactoring things, but if there truly are no breaking changes, I get to focus more on like the cool refactor stuff, right? And that's what I think is really cool. Yeah, yeah, for sure. And I guess just from like, say you're running, say like you've got this old app, it's running, I don't know, Laravel 10, and you're now Laravel 12 is about to come out and you're like, well, I really need to be on Laravel 11.
You, I guess the recommended pathway for shift is you would go and run the 10 to 11 shift, do that, and then run the 11 to 12 shift once it's out. Is that sort of the flow you like to do? Or is it just like boom, 10 to 12, and then you have like even more commits, I guess. Yeah, old shifts are always incremental. And this is kind of for focus and context.
I mean, if you were on LayerVille seven, eight, nine, 10, whatever, and you tried to jump in one shot to 12, you know, and then there's an error. Well, where did the error happen? Did it, where do I go look to get help? Do I look in the context of LayerVille 11? Like how do I refine that search, right? Or that prompt to like know what I'm looking at?
I mean, hopefully you have a good error message, but I find that the incremental ones help again with that context of like, okay, I'm going from 10 to 11, and now I got this error. And it's very, you know, just throwing on LayerVille 11 and the error is gonna give you far better results, far better information if you were to encounter a problem.
Then, you know, again, if you're trying to lump some upgrade several versions, you kind of just don't even know where you're aiming if you run into a problem. And that alone, that single error can burn all the time that you would have spent running one extra shift, right? Yeah, that actually brings a question. This is totally theoretical. If you're on a Laravel seven app, Laravel 12's coming out.
I don't, I mean, it would take you a month to go through all the code changes without going through shift. I mean, like, I don't even know if that would be fun or possible without shift. I think a lot of people think when they get that far behind, oh, I'll just make a LayerVille new and then copy my code over. A lot of people think that's what I can do. But that completely dismisses all of the code changes, like things change, traits change, facades change, method signatures change.
So really, again, all you're doing is, sure you have a new LayerVille 12 app, but you're bringing in all your legacy code over. And yeah, it might run, but the same thing. Some day when the wheels fall off that, and they will, some day, you're gonna have no context of what broke. You're gonna have no information because you're just gonna think kind of naively, like, oh, I was running LayerVille 12. Well, not really. You were running LayerVille 12 of a LayerVille seven code base, you know?
And that's just gonna be a problem, so. That's very true. So I guess if you go back in time, like in the beginning, why did you, or what just spurred you to be like, hey, I want to create this thing that will auto upgrade people, as far as the beginning of Flurival Shift?
Sure. The origin story in a nutshell, and I think one of my last, the last kind of series of our base code podcasts that I used to do with Jess, I kind of did a solo series at the end that went through kind of the genesis of Shift. And honestly, it was kind of like a historical record for me because I'm going in the 10th year of Shift now, and I've got kids now, I don't sleep as much. Like, I was kind of forgetting some of the details, right? I mean, it's been a while.
But the short story is, I was at a PHP conference and Taylor was there, and I gave a talk on upgrading at the time. This was, it was upgrading from Laravel 4.2 to 5, a big, huge, major release. And after the talk, I caught up with Taylor and I was like, hey, do you know of any scripts that help with this? Or, you know, have you thought about it? And he was like, you know, man, a few words. Of course he was like, no, but I'd use it. And I was like, you know, whoa. Light bulbs, right?
So like that night at the hackathon, I worked on some scripts that would automate a lot of these things, right? Because again, it was folder structure moves, it was files changed, it was, okay, now controllers extend this other controller, okay, now models are name spaced, like all these things, right? That could be automated. And I think it was funny, he was, as a bit of history, he was hacking on this little JavaScript framework called Vue and trying to bring it into Laravel 5.1.
And so it was interesting, because I was kind of bouncing ideas off of him and really kind of the rest is history. From there, he released 5.1 and I packaged these scripts up and I put them on this little website for three bucks. It was $3, the first shift. And it was great. People like, I didn't, I was new to the community, but people like Frake and Jeffrey Way and Taylor himself were kind of using it in those first few weeks.
You know, you're watching the little Stripe emails and you're seeing these names and you're learning the community and you're like, oh my gosh, that's layer casts, you know? And I'm getting feedback and it's just been that times a million, you know, since then. Yeah, that's amazing. That's sort of the coolest way products or apps start. It's just like talking to somebody and being like, oh yeah, I think that'd be amazing. And then you're just like, okay, I'm just gonna build this.
So to kind of shift gears a little bit from the page shifts that you run and basically run your business, but as a community service, you send PRs to open source packages. So that way they can be up on layer build 12. At the moment, I guess what the moment Laravel 12 was out there able to go ahead and merge your pull request and be supported on Laravel 12. Yeah, that's honestly the biggest drag.
And again, going back to kind of the no breaking changes, like sure, there might be no breaking changes from the framework, but there's still going to be things that make your upgrade challenging or things that you might have to do. And one of the biggest always has been third party dependencies. You know, oh, this one's not compatible for Laravel 12.
I mean, we've all seen that huge dump of a composer, super technical message, problem one, problem two, problem three, problem infinity, like, oh my God, you know, and it's just like 17 package, illuminate view, you know, 4.7, it's like, I don't even know what's going on here. It's just so much information to digest. So I hope to help people stay away, you know, from that. I hope to kind of protect them from that in a way.
And so over the years we had this tool Jess and I worked on a couple of years back, it's caniupgradelayervel.com and it just redirects to a little service within shift. You can paste in your composer JSON file and we kind of give you check boxes of what has compatibility. But over the time, I actually started to take some of that data that, you know, you're giving us your list of packages that you use and we can kind of start to rank them.
I was already doing this anyways, when you ran shift to know, well, what are the big packages like layervel collective HTML? It used to be a huge package. Every application used this thing. And because of that, it helped me make shift better because now I know, okay, if there was a big breaking change in layervel collective, I'm gonna go ahead and do it too.
Even though it's not layervel directly like framework related change, I'm going to go ahead and put this in whatever shift it was, just cause again, it makes developer life's easier. So this is all an effort again, to kind of just make that upgrade process seamless cause there's always stuff you have to do. And if I can, there's always something that's going to be automated or automatable. And this is kind of the last frontier, if you will.
If I can truly even at a third party level start to bump dependencies or let you know, okay, this one has their own upgrade guide, and who knows maybe someday even start to automate pieces of that for very popular packages. That would be ideal. Cause then you can truly run shift, you can merge, and it's just all kind of seamless.
So helping the community get there, helping the community not have that drag is important, not just for shift, but hopefully, you know, layervel and the community at large. I mean, you know, by comparison, look at communities like WordPress, for example, and avoiding all the WP drama and all that stuff. Like those communities are in a way, you know, burdened by the kind of legacy of the code, again, cause of their sheer size of that community.
You know, you probably have sites running WordPress three something still, right? And I don't know the latest greatest version of WordPress, but the point is that WordPress themselves doesn't want to alienate that WordPress site still running version three, right? So like they can't move as quick. And I don't think layervel would ever want to be in a place where they can't move as quick as they are, right?
That's kind of a signature, that's kind of a, again, a trait of the community is kind of moving quick and adopting new features and just shipping, shipping, shipping, right? You can't really ship if everybody's still running layervel four two and no packages are layervel 12 compatible, right? Like it just, that's where I tease for another nickname and kind of call myself the garbage man. Like I'm taking out the trash, so our city stays clean, right? Our community stays clean.
We don't have those as many of those four two apps floating out there that can't do all the cool. It doesn't matter all the cool stuff you talk about, if no one can do it, no one can run it, right?
Exactly. And two, I mean, just, you know, being around a long time, there's been so many releases where like I have this obscure package and it's like, it's just forgotten about, you know, GitHub and you like go and make a comment and be like, "Hey, can you bump the version dependency to whatever, "illuminate 10 or something?" Yeah. And it's just dead silent, you're like here to nothing. And it's like, well, I can't update until we get this fixed.
And then it's like, oh, well, now I gotta go figure out how to like run my own fork of this package. Yeah. It's just the whole thing. And so, you know, I greatly appreciate you doing this as a community service on that angle, because I think it is hugely beneficial for maintainers and for the people that are just waiting on these updates that they can't get. Yeah, yeah. Again, I just think it's an all around good community service.
Like sure, you can peg it as marketing for shift or whatever, but I'm not making anything directly off of those PRs. They just truly help the community. They help me. I mean, just like you, I use third party packages that, you know, Vimeo is a prime example. I think Ben and I always tease about this, that like, you know, that package has never, it'll be like August and it still is not Laravel 12 compatible, you know? It's been six months since the release.
But you know, day one, you can at least see the PR from shift. And a lot of times it is just simply a composer dependency bump. You know, there's not, again, no breaking changes. There's not anything that you need to do theoretically for Laravel 12 other than just make sure your composer compatibility exists. Yeah, so here's a question. So I did a little AMA on Instagram where I was just like, hey, I'm going to interview, you know, JMac from Laravel shift, you got any questions?
So one of the questions were is does Laravel shift, let me see if I can speak, does Laravel shift support complex updates? And there's they didn't give really in context, but I'm assuming like one of these, you know, crazy apps that people just built back in the day that has all this crazy stuff. Does it have support for like out of the box things or is or do you take that question a different way? Maybe that's the maybe I should ask you your opinion on it.
There's probably a lot of different ways you could read into complex. My guess is probably the way in which they they're structuring the app. Right. Maybe maybe they're doing some quote unquote unconventional things. Right. So I think historically, there might have been more truth to the fact that if you use, if you followed Laravel conventions, that shift is for those conventional apps.
I think that might have used to be true, like early Laravel 5 versions, but probably around 5.6, 5.7, I started switching to more static analysis inside of the shift, you know, what I call the engine. And once I did that, it really didn't matter what conventions you follow because I'm really just parsing PHP at that point. I'm not looking for like Laravel syntax per se, right? I'm just, hey, if you've got X method in your abstract syntax tree, like I'm going to do something with it.
And so at that point shift became much more robust for complex applications or applications that are unconventional. Like if you mean complex in the sheer size of code shifts a computer, it doesn't matter. It doesn't matter if it's a hundred thousand files or 10 files in your app. It doesn't matter if you have 200 controllers or 300 models, it doesn't matter. It might take five or six more seconds to run, but as far as the automation itself, it is not more complex just because your app is large.
So I think complex apps probably means, you know, maybe you have your own namespaces, you've subnamespace things, you know, maybe you're following like a modular design. For the most part shift is going to handle those without any problem. I think the only area where it gets, where it might get a little funny is, again, if you're following a modular design with a very opinionated, you know, there's some third party packages that do modular domain design and they're very opinionated.
The way in which they might structure that code, they're probably things that shift could miss, but the argument would be that, well, that's the upgrade guide for that package. Like you chose to use that package and therefore you're choosing to take on, you know, you made a trade off to take on that upgrade framework as well, right? Like you're kind of using a micro framework in that scenario. So you have to go upgrade it on your own. I didn't make a shift for that thing.
So yeah, that makes sense. Yeah, the I'm always curious to like, when I think complex, I think of like the modules like you alluded to, but I'm a, you know, with there's so many little apps out there, I'm sure like you've seen some of the craziest stuff that's been created. And modules is probably not the craziest. No, no. Yeah, I mean, if you're if you mean complexes and you don't use eloquent and you use doctrine directly, yeah, I probably can't help you too much there. Sorry.
So there are boundaries for sure. But yeah, if you if you do things mostly conventional and, and, you know, let you're not using any kind of against sub package that has its own conventions that if kind of exists in your application, I think that, you know, shift shift is going to have you 100%.
But yeah, and the other thing to you to the point that you said, and again, the whole thing of 10 years and the upgrades and the context, you know, I've answered thousands of emails that have, oh, well shifted great, but it missed this, right? It missed this little, here's the little myth, because every everyone that runs a shift, especially the new ones, I have a follow up email and I say, hey, how'd it go? Did you have to make any manual changes? I read every single one of those.
I've done that for 10 years. So the the depth that shift can go to make, you know, these changes, it's not again, it's not just the upgrade guide. It's the upgrade guide plus 10,000 of your fellow developers that are giving me feedback and saying, Oh, this is good, but here's this other change. It's not documented, but it affected us. Add automation for it, add a PR comment, add something, something's going to be in shift that's going to let you know.
So sure, while something maybe wasn't a breaking change or even documented, shift is probably still going to sniff that out, or it's still going to do that for you. And you'll, hopefully, you're never the wiser, right? Because that's the whole point, just make it easy. But it's in there. That domain knowledge is it's all right here. I love that. Yeah, it's one of those under the radar services that I think is unique to Laravel that a lot of other communities do not have.
And for me, it's just like, it's like the perfect add on to a framework. It's like, this is this is great. And that's that track. I appreciate you doing it. Yeah. Yeah. And no, I appreciate it too, because I think that's where I take a little bit of that self-pride. Again, I joke and say garbage man, but those other communities, they might have this drag that I'm talking about because this service is missing. And so I'm glad to have made it and to offer it if that's what it's doing.
Because again, that was always kind of the sub-goal. Sure, I needed to use this myself way back in the day. And sure, Taylor gave me some motivational words. But the fact that it's still here is because it's bringing that value. And again, there's always going to be changes to make in every application. And I'm glad that the community sees and appreciates the value of that. And I hope that it helps keep Laravel charging ahead. Right. For sure. For sure.
As far as my questions, you have answered all of them. Thanks. Did I miss anything you want to talk about while we're on here? I don't think so. You know, again, I'm looking forward to the Laravel 12 shift, not just because the release date is soon. You know, I kind of start to breathe easy after the Litterville 12 shift is done. But also so many other things that, again, Litterville is just shipping, shipping, shipping. So many other things. Clouds coming out, the new starter kits.
And maybe there's opportunity there in the starter kits. Maybe there's a shift for old starter kits to get you into the new starter kits. You know, so there's so many things that shift is always going to be able to look at that, even if, you know, there just truly was some kind of seamless, beautiful upgrade built into Litterville. You know, I think shift would still have a place, hopefully within the community.
But I'm looking forward to making a lot of like the Litterville 12 shift is actually pretty big for what I've built so far. I'll probably have a pre-release early next week. I like to have a pre-release to let those early adopters test shift, but also Litterville 12, right? Like, you know, get more people maybe using it before it's released. You know, I'm excited for the automation. And I've done a lot. I've been able to focus a lot more on the conventional refactors this time around.
I think the people that stick around and use the Laravel 12 shift are going to be surprised at just like you were with Laravel 11 on the stuff that comes across. It's always going above and beyond. And it's definitely going to do that this time. Yeah. Well, yeah. To me, it too, this sort of comes back to like you said about WordPress. Like if you have WordPress version two, it might still run. But you're missing out on all the new features that's been launched since then.
And, you know, I don't even know if there's an easy way to upgrade WordPress. I assume there might be. I don't know. But yeah, that's just wild. But yeah, man, well, I want to say thank you for coming on, spending some time with us and going through all the stuff. You know, I'm really looking forward to Litterville 12, Litterville shift, seeing you at Laricon. Oh, yeah. All right. Good, good, good. Yeah, I'll be there. I already got my ticket, but I submitted a talk or two this time around.
So I'm hoping maybe I can land on stage. But the team is so large now that I don't know. That's some tough competition. We'll see. But I'd love to be able to get on stage again someday before I'm too old man, JMac. We'll see. That sounds good. Well, thank you, JMac, for coming and being on the show. Cool, man. See you.