Just shy of a month ago, I shared some information about the state of the WordPress Plugin Boilerplate.
Specifically, I mentioned the following:
- We’re working on rewriting it to be cleaner, easier to understand, and more flexible for developers of all experience.
- I’ve got a small, core team of volunteers helping me out (who I greatly appreciate).
- Where we’re headed with this latest version of the project.
To be honest, I’ve never been more excited about the project.
There’s a lot more coming down the pipeline that I’ll cover later in this post – I also want to clear up some fun versioning quirks that I’ve been asked about – but I wanted to give a heads up on the current state of the codebase and where you can follow along with the development as we begin to push code.
The WordPress Plugin Boilerplate: develop
First and foremost, the `master` branch of the WordPress Plugin Boilerplate is going to stay stable and set at `2.6.1.`. All work is being done in a completely separate branch so not to interfere with those who are currently watching the project and using it for their work.
That said, all of the new work that’s going into the new rewrite is being done in the `develop` branch. You can follow along with the progress that we’re making on that particular branch.
At this point in time, we’ve only just pushed the directory structure live so there’s no much to see right now.
Milestones and Issues
Because of the way that GitHub manages milestones, you can’t assign milestones to specific branches. As you can see, we’re working to keep all issues and tickets related to the rewrite under milestones prefixed with “[develop]”.
This will allow us to more easily track issues that are related to the core Boilerplate and those that are going into the rewrite separately.
Yes — we will be taking some tickets from the existing milestones and merging them into milestones [that have yet to be created] for the `develop` branch; however, some tickets may be closed for consideration, at least for this moment in time.
This is being done so that we can more correctly align the outstanding tickets with the goal and vision for the rewrite, and make sure that we’re properly focusing our efforts.
Accepting Pull Requests
Right now, we have a very specific roadmap that we’re planning to focus on at least for a while, so even though we welcome pull requests, there’s a strong chance that those that are issued early on in this project will be rejected or at least delayed.
It’s not because we’re against open source – obviously – and it’s not because we don’t welcome contributions. It’s just that there’s a very set of specific things that we want to get in place prior to doing anything else.
That said, feel free to issue them, but if they are closed, don’t take offense (though I argue that we shouldn’t even have to provide this disclaimer), and feel free to offer it up again in the future.
You Keep Saying Roadmap (“Can I Help?”)
Yep – when I put out an invitation for help on the mailing list, I had a few people respond who were interested in hopping in to help plan the next iteration so, in typical first-come-first-serve fashion, that’s what we did.
Once the Boilerplate reaches a level at which the core team has achieved our initial set of goals, we’re going to need more help. This, obviously, is where the open source nature of the project shines.
Additionally, we’ve got some really neat plans for this version of the Boilerplate that take it beyond a simple GitHub repository.
Here’s where we are headed and what we’ll eventually need help with:
- We’ve purchased a domain off of which we’re going to host a site, blog, documentation, and more for the project.
- A primary landing page for the project complete with an icon and/or branding, color scheme, and all of the other material that goes with creating a well-rounded project.
- We’re going to have tools and documentation specifically geared towards beginners, intermediates, and advanced programmers based on the type of plugin that you want to build.
- …and much more.
So if you’re interested in lending a hand with any of the above, then shoot me an email and we’ll chat about coming along to help us out.
Oh, And What’s With the Versioning Scheme?
So Remkus noticed that the `develop` branch is currently tagged as `0.1.0` when the latest version of the Boilerplate is at `2.6.1`.
For those who have read this blog long enough know that I am a fan of semantic versioning and try to use it when I can for each project.
The way I see it, the development branch of the rewrite of the Boilerplate is like starting over. As such, we’re starting with tag `0.1.0` and we’ll eventually be moving our way up. Once the time comes for final release, we’ll merge the `develop` branch into `master` and officially tag master as `2.7.0`.
Confusing? Maybe. But it works with how we’re building out the project and that’s the strategy that we’re going to be using.
On To Development
Hopefully this gives more information about the status of the Boilerplate, why I – and the team – are excited about it, where we’re headed, and what to expect in the coming months.
Can’t wait for us to make more progress on it.
In the meantime, follow along on GitHub or keep up with this particular blog until the official blog for the project’s landing page and blog go live.