Posted on

Tentative roadmap for the 0.9.9 and 1.0.0 releases

Since the idea behind calmPress is to create and maintain an improved version of WordPress over time and not just to divorce WordPress here and now, we are, and will always be, dependent in some way on the release schedule of WordPress itself.

Now that there is an actual roadmap for versions 4.9.9 and 5.0 of WordPress, it is possible to at least get some ballpark dates for the release of versions 0.9.9 and 1.0.0

0.9.9

This version is meant to provide a simple migration step from WordPress to calmPress. The most important feature of it is changing the software update mechanism from getting core updates from wordpress.org to getting them from calmPress.org.

There were some other changes, but they were mostly focused on branding related changes.

Read the full release change log

The current status of the version is that it is a beta quality software, all planned features were coded and no new features will be added.

The plan was to release it when WordPress 4.9.9 version will be released, but the recent changes to the WordPress roadmap due to the release of Gutenberg in version 5.0 “pulled the rag” from under the 4.9.9 planning and at this time it is not clear if and when such a version will be released (although it is needed if WordPress wants to support PHP 7.3 for the 4.9 branch).

As we have no idea about when WordPress will have such a release, we will just go ahead and release 0.9.9 on the the 2nd of November 2018.

1.0.0

The first release in which we will start to show our long term vision. It will have the following focuses

  • Essential and easy implement security improvements. They are going to be about removing XML-RPC, preventing external access to places to where there is no reason to have such access, and remove the exposure of user names.
  • Introduction of a core plugins concept. Those plugins will be an answer to the situation where many people need a feature, but not enough to justify having it in core, and they will be maintained directly or indirectly by core.
  • Deprecation of  code and features that should have died long time ago. Starting with the generator tag, emogies,  code editing from the admin, XML-RPC, RSS feeds, own oEmbed support, and more. Some of them will be moved to core plugins, some will be removed and most likely there will be no one that will shed a tear.

Read all the features we expect to push in version 1.0.0

We will try to release this version at the 8th of February 2019.

Posted on

The agitation created with the WordPress 5.0 roadmap is exactly what we want to avoid

Change is hard, and no matter what some people say, no one likes unsolicited change.

But change is also a fact of life. You will never grow and improve if you just blindly reject change.

The question is always about the balance which you need to keep between investing in change while still staying sufficiently safely in your comfort zone, and how you facilitate change.

We think that the roadmap for WordPress 5.0 is a great example of how to not facilitate change and a total antithesis to what we believe in.

You should read the roadmap first if you are not familiar with it. It is important for context that while everybody was aware that there will be a 5.0 release at some point, but too many promised deadlines that had passed left everybody wandering when will that happen.

One day out of the blue there is an announcement that version 5.0 will be ready for production (RC milestone) in less than 4 weeks, it will not include feature that were already worked on trunk (and people might have expected them to be in 5.0), but will include updates to all core themes, and a new theme that no one ever talked about before.

Time to General Availability from announcement? about six weeks.

People complain about dates coinciding with busy holiday and shopping season in the US, and while it is true (as core contributor pointed out) that it is always a holiday or shopping rush somewhere in the world, the real issue is that a two months time is relatively short and people might have already made commitments for that period of time and they just do not have the available time to invest into checking their software’s compatibility with the new version and produce fixes if needed.

And it gets even worse, because in case it will be needed, the time to GA might end up being four months in the future instead of the promised two. No one can realistically plan anything based on such a fuzzy schedule.

In calmPress we simply reject this kind of planning. For us it is not the issue of the kind of change (yes, I personally hate gutenberg as much as the other 50% of WordPress users do), but the realization that users should be provided with as many tools as possible to both prepare for a change, and postpone it until they can make the time to deal with it.

We do expect a relatively fast release cycles while we are working on transforming a vision into actual code, but the ultimate goal is to have a slow release cycle, maybe even as slow as having no more than one major release a year like PHP itself has. We know that people become nervous and agitated when they need to confront a change, especially if they are not very technical, and we want to keep them as calm as possible and let them focus on content creation and not on site maintenance.