The Latest Branch of the WordPress Plugin Boilerplate

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.

develop -  WordPress Plugin Boilerplate

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.

6 Comments

I am not sure how much it applies to a boilerplate but a rewrite screams MAJOR to me and so should be a bump to 3.0. Right?

    The short answer: Maybe (and you’ve raised a good point!).

    As of right now (and by semver standards), there won’t really be any major API changes (in fact, there isn’t really a major API to begin with :) so the next bump selected is `2.7.0`.

    That said, things can change so depending on how it goes over the next few code pushes.

    Some other notes from the Semantic Versioning site:

    If even the tiniest backwards incompatible changes to the public API require a major version bump, won’t I end up at version 42.0.0 very rapidly?

    This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you’ll think through the impact of your changes, and evaluate the cost/benefit ratio involved.

    Emphasis added is mine.

    Since it really isn’t an API change, I’m skeptical about bumping to `3.0.0` – not opposed, just skeptical.

    We’ll see what happens, though :).

    Yeah, I’m going to have to go with Christian. Not going for 3.0.0 is just too quirky ;)

Great to hear, Tom. I’ve been concerned that it was becoming a bit of a behemoth, and quite daunting for those with less experience. Given it is loaded up with help and todo info, it seems to be aimed at the less experienced.

It’d be nice too if there was a trimmed version, with none of that for those who don’t need it. Maybe all that help info should be separated out into a help document.

I also think it’s outgrown the term “boilerplate”. I think it’s more of a framework now. That could be just be my localised understanding of the two terms.

    I’ve been concerned that it was becoming a bit of a behemoth, and quite daunting for those with less experience.

    Spot on – that’s exactly why I wanted to do this rewrite and get a team of core people around it so that we can create very specific pages of documentation, FAQs, and even custom downloads based on your level of experience.

    I also think it’s outgrown the term “boilerplate”. I think it’s more of a framework now. That could be just be my localised understanding of the two terms.

    Personally, I still very much view is as a Boilerplate — perhaps I should do a post on this as to why.

Leave a Reply

Name and email address are required. Your email address will not be published.

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>