We've had a roadmap page on concrete5.org for awhile. It's generally been a high-level affair, with us sharing some general thoughts about the direction of the platform. But it's hardly been the specific, granular roadmap that people have been looking for. That's going to change today.
We've flirted with GitHub milestones before, but we haven't really used them in a coherent capacity. Going forward, GitHub milestones are going to become the source of truth for the status of a major release. Want to see how a release is going, what's going in it, and what's left until it's ready? Check the milestone. Here's what's left to be done until 8.4.0 is ready.
Fortunately, you don't have to go to GitHub to get this information. The new concrete5 Roadmap can give it to you in realtime, for all releases.
The Big List
There are tons of issues that aren't assigned to a milestone. What's the deal with them? Basically, any issue that has "help wanted" and "like to have", "love to have" or "must have" tagged on it is fair game for an interested community member. If it's not in a milestone, that just means that it isn't something we've deemed essential to a particular release. But we'd still love to have help with it! For example, if you want to help with any of these "love to have" items, I'll send you a fruit basket:
(These are issues that we'd love to have help on, with no milestone and no assignee.)
"When it's Ready"
While there's a GitHub date "Due On" field listed on these milestones, don't be fooled: this date is meant to sort the milestone in the list, and nothing more. While these major releases may be fueled by our own internal marketing efforts, most of the time they will be dictated by the features that we've put into them. Simply put: want to know when 8.4.0 is coming? Help us clear out the milestone list!
Once a milestone list is cleared of issues, we will issue a release candidate. If that candidate turns out to be bug free, the release will come next! (Curious about how concrete5 does version numbering? I've added it to the documentation.)
While minor releases like 8.4.1, 8.4.2 may show up as milestones (with the same requirements as the major releases – gotta get them done), it's more likely that they will be released as necessary, following major releases. That's how we've always worked.
We still love unsolicited pull requests, and will try and get them into the core in a timely fashion. If the pull request is too large an overhaul or too experimental for the develop branch of GitHub (which is currently 8.4.0, but is frequently a point release like 8.3.1), we may move it to a later release branch. As we get pull requests that still need work, we'll add them to milestones so that they show up as things we need to get working for a particular release.
I'll be adding more granular issues to the 9.0 milestone issue list soon (since right now it's fairly high level, doesn't necessarily communicate all the things we'd like to have done in 9.0). In the meantime, please check out 8.4.0. If you can help us get it over the finish line, we'd love to hear from you.