In the forty-fourth episode of the WordPress Briefing, our host Josepha Haden Chomphosy highlights the role of major and minor releases in the WordPress open source project.

Have a question you’d like answered? You can submit them to wpbriefing@wordpress.org, either written or as a voice recording.

Credits

Editor: Dustin Hartzler
Logo: Javier Arce
Production: Santana Inniss
Song: Fearless First by Kevin MacLeod

References

Twelfth Man
State of the Word

Transcript

[Josepha Haden Chomphosy 00:00:00] 

Hello everyone! And welcome to the WordPress Briefing, the podcast where you can catch quick explanations of the ideas behind the WordPress open source project, some insight into the community that supports it, and get a small list of big things coming up in the next two weeks. 

I’m your host, Josepha Haden Chomphosy. Here we go.

[Josepha Haden Chomphosy 00:00:27] 

At the top of November, a new major release for WordPress shipped. That was WordPress 6.1. I know I talked about it basically nonstop. Then two weeks later, there was a new minor release for WordPress. It was WordPress 6.1.1, which I did not talk about at all. Way back in episode four of this podcast, I dug into the overall release cycle and what someone could expect from a high-level logistics aspect.

[Josepha Haden Chomphosy 00:01:05] 

And today we’re gonna take a quick look at minor releases in particular. Just as a general heads up, I always want to lean into sports metaphors when I’m talking about releases, and I think it’s because of the words major and minor. And so, I’ve done my level best to not include that in any of my explanations today.

But I do have one, I do have one that’s a sports thing. So just if you don’t like sports, know that it’s just one little bit and we’ll try to be carefully quick around it together. All right, so minor releases. You may have noticed that I don’t mention minor releases nearly as often as I mention major releases. And yet, most of the time, when we have a major release of WordPress, there’s a minor release that gets started almost immediately after.

So first major versus minor. Major releases in WordPress happen roughly three times a year, give or take a release. Inside a major release, you will find that we include features, so– brand new abilities, enhancements, which you can generally call improvements to existing abilities, and also any bug fix that we can find, big or small, we’ll take ’em all.

[Josepha Haden Chomphosy 00:02:16] 

So minor releases in WordPress happen about four or five times a year on average. Minor releases include patches for issues introduced in the major release and any bug fix that doesn’t add or change functionality. 

If you’re with me so far, you probably have noted that there’s basically always at least one minor release per major release. And you might have also noted that I said minors include patches for issues we introduced in a major.

Now, if I were hearing this with fresh ears, the first thing I would wonder is, okay, so if you start working on the minor right after you release the major to deal with issues you know you introduced in the major– why just not ship the major while there are bugs in it? Great question. I’m glad you asked. So there are a few things worth knowing here.

[Josepha Haden Chomphosy 00:03:09] 

Firstly, there is this concept of “ship and iterate,” which is present in both agile and open source. The idea is that we ship software as soon as we have confidence that what is in the release is non-breaking and represents our best guests at a better experience for our users.

Once that is out there, we use feedback on the initial release to quickly iterate and ship another release. That way, we don’t hold back any good features. And since we already planned the immediate minor, any major issues that show up can be fixed in as little as two weeks. Secondly, there is the concept that with many eyes, all bugs are shallow, which is primarily present in open source.

The idea here is that with enough people looking at a problem, that problem doesn’t stand a chance. So when a release is shipped in a workable state but with interactions that could use some refinement, the fastest way to find those refinements is to take it to the community of WordPress users and developers and invite them to co-create this CMS with us.

[Josepha Haden Chomphosy 00:04:10]

Which touches on my final thought. The concept of the user as co-creator.

If we think about the development and evolution of our software as a team effort, then we can think of the people who use our software as what’s called the “Twelfth Man” That’s in quotes, and I will, I’ll leave a link to that in the show notes as well. 

In sports, this refers to the fans. And if you’ve ever been to a live sporting event or played in any, you will know that the cheering and jeering from fans turns into this distinct motivating entity all its own. As a whole team or individual member, you know what you have to do. You know what you need to do in a game, but there’s something about that chaotic, loud roar of feedback that just brings life to what you’re doing, and that’s how I see our community of users.

[Josepha Haden Chomphosy 00:05:02]

So at the end of the day, the answer to the question of ‘why so many releases’ and the follow-up question of ‘why tolerate stable imperfection’ is largely the same. To get features into the hands of our users quickly so that we can always be breathing life into this CMS we care so much about.

I hope that answers your questions about our release cadence, and if you didn’t come into this podcast having any questions about release cadences at all, I hope this new information brings a little extra light to the complexity of working in open source. 

[Josepha Haden Chomphosy 00:05:32] 

That brings us now to our small list of big things.

Big thing number one is that the State of the Word has been announced and is scheduled for December 15th. It’s a little earlier in the day than in past iterations, so I hope we get a new crew of listeners tuning in at the same time. I’ll leave a link to that in the show notes, or you can pop over to wordpress.org/news to see the announcement for yourself.

[Josepha Haden Chomphosy 00:06:00] 

Big thing number two is that team rep nominations are open on most teams right now. So if organization and people wrangling are high on your list of ways you can give back to WordPress, head on over to the team you contribute to and see how you raise your hand for that. 

Then big thing number three is that big-picture goals, hopes, and timelines are being gathered, and I will ship those shortly after the start of the new year.

It will give us all an idea of where we want to focus our attention to ensure that WordPress continues to grow toward the future. You can keep an eye out for that on make.wordpress.org/project. 

And that, my friends, is your small list of big things. Thanks for tuning in today for the WordPress Briefing. I’m your host, Josepha Haden Chomphosy, and I’ll see you again in a couple of weeks.

In the forty-fourth episode of the WordPress Briefing, our host Josepha Haden Chomphosy highlights the role of major and minor releases in the WordPress open source project.

Have a question you’d like answered? You can submit them to wpbriefing@wordpress.org, either written or as a voice recording.

Credits

Editor: Dustin Hartzler
Logo: Javier Arce
Production: Santana Inniss
Song: Fearless First by Kevin MacLeod

References

Twelfth Man
State of the Word

Transcript

[Josepha Haden Chomphosy 00:00:00] 

Hello everyone! And welcome to the WordPress Briefing, the podcast where you can catch quick explanations of the ideas behind the WordPress open source project, some insight into the community that supports it, and get a small list of big things coming up in the next two weeks. 

I’m your host, Josepha Haden Chomphosy. Here we go.

[Josepha Haden Chomphosy 00:00:27] 

At the top of November, a new major release for WordPress shipped. That was WordPress 6.1. I know I talked about it basically nonstop. Then two weeks later, there was a new minor release for WordPress. It was WordPress 6.1.1, which I did not talk about at all. Way back in episode four of this podcast, I dug into the overall release cycle and what someone could expect from a high-level logistics aspect.

[Josepha Haden Chomphosy 00:01:05] 

And today we’re gonna take a quick look at minor releases in particular. Just as a general heads up, I always want to lean into sports metaphors when I’m talking about releases, and I think it’s because of the words major and minor. And so, I’ve done my level best to not include that in any of my explanations today.

But I do have one, I do have one that’s a sports thing. So just if you don’t like sports, know that it’s just one little bit and we’ll try to be carefully quick around it together. All right, so minor releases. You may have noticed that I don’t mention minor releases nearly as often as I mention major releases. And yet, most of the time, when we have a major release of WordPress, there’s a minor release that gets started almost immediately after.

So first major versus minor. Major releases in WordPress happen roughly three times a year, give or take a release. Inside a major release, you will find that we include features, so– brand new abilities, enhancements, which you can generally call improvements to existing abilities, and also any bug fix that we can find, big or small, we’ll take ’em all.

[Josepha Haden Chomphosy 00:02:16] 

So minor releases in WordPress happen about four or five times a year on average. Minor releases include patches for issues introduced in the major release and any bug fix that doesn’t add or change functionality. 

If you’re with me so far, you probably have noted that there’s basically always at least one minor release per major release. And you might have also noted that I said minors include patches for issues we introduced in a major.

Now, if I were hearing this with fresh ears, the first thing I would wonder is, okay, so if you start working on the minor right after you release the major to deal with issues you know you introduced in the major– why just not ship the major while there are bugs in it? Great question. I’m glad you asked. So there are a few things worth knowing here.

[Josepha Haden Chomphosy 00:03:09] 

Firstly, there is this concept of “ship and iterate,” which is present in both agile and open source. The idea is that we ship software as soon as we have confidence that what is in the release is non-breaking and represents our best guests at a better experience for our users.

Once that is out there, we use feedback on the initial release to quickly iterate and ship another release. That way, we don’t hold back any good features. And since we already planned the immediate minor, any major issues that show up can be fixed in as little as two weeks. Secondly, there is the concept that with many eyes, all bugs are shallow, which is primarily present in open source.

The idea here is that with enough people looking at a problem, that problem doesn’t stand a chance. So when a release is shipped in a workable state but with interactions that could use some refinement, the fastest way to find those refinements is to take it to the community of WordPress users and developers and invite them to co-create this CMS with us.

[Josepha Haden Chomphosy 00:04:10]

Which touches on my final thought. The concept of the user as co-creator.

If we think about the development and evolution of our software as a team effort, then we can think of the people who use our software as what’s called the “Twelfth Man” That’s in quotes, and I will, I’ll leave a link to that in the show notes as well. 

In sports, this refers to the fans. And if you’ve ever been to a live sporting event or played in any, you will know that the cheering and jeering from fans turns into this distinct motivating entity all its own. As a whole team or individual member, you know what you have to do. You know what you need to do in a game, but there’s something about that chaotic, loud roar of feedback that just brings life to what you’re doing, and that’s how I see our community of users.

[Josepha Haden Chomphosy 00:05:02]

So at the end of the day, the answer to the question of ‘why so many releases’ and the follow-up question of ‘why tolerate stable imperfection’ is largely the same. To get features into the hands of our users quickly so that we can always be breathing life into this CMS we care so much about.

I hope that answers your questions about our release cadence, and if you didn’t come into this podcast having any questions about release cadences at all, I hope this new information brings a little extra light to the complexity of working in open source. 

[Josepha Haden Chomphosy 00:05:32] 

That brings us now to our small list of big things.

Big thing number one is that the State of the Word has been announced and is scheduled for December 15th. It’s a little earlier in the day than in past iterations, so I hope we get a new crew of listeners tuning in at the same time. I’ll leave a link to that in the show notes, or you can pop over to wordpress.org/news to see the announcement for yourself.

[Josepha Haden Chomphosy 00:06:00] 

Big thing number two is that team rep nominations are open on most teams right now. So if organization and people wrangling are high on your list of ways you can give back to WordPress, head on over to the team you contribute to and see how you raise your hand for that. 

Then big thing number three is that big-picture goals, hopes, and timelines are being gathered, and I will ship those shortly after the start of the new year.

It will give us all an idea of where we want to focus our attention to ensure that WordPress continues to grow toward the future. You can keep an eye out for that on make.wordpress.org/project. 

And that, my friends, is your small list of big things. Thanks for tuning in today for the WordPress Briefing. I’m your host, Josepha Haden Chomphosy, and I’ll see you again in a couple of weeks.