It’s not the release schedule, its the lack of succinct documentation on changes to the back end that I have a problem with.

You have to accept that in community development, it’s easy to get volunteers to work on the cool and exciting bits, but not so easy for the boring things like documentation. This is where Automattic have a role to step in and fill the gap.

I believe the metaphor is wrong. The Wordpress site is more like a Mall — one place to go to that offers various stores — , and the Plugin authors the stores in the mall offering their little plug-in products.

And, it does not take ANY technical knowledge at all to understand what “compatible up to version x.x” meant. It is just like reading the expiration date of the milk you bought at the supermarket.

Add my two centavos to your two cents.

Name calling won’t change things and is not very constructive.

I think the point was made by a few posters already that some changes that could affect plugins should be documented (and I don’t mean through Trac, because that doesn’t call out a particular change).

Whether it’s a change that could break a plugin, a new way of doing things that plugin developers should adopt, or just new functionality that some plugins might be very happy to adopt, it would be very helpful to developers to have something posted at release time - or before - that identifies the changes and recommends how plugins (and even themes) in general should deal with them in their code.

WordPress’ codebase is large, and to have to dig through Trac, or dig through all the code, or Google and search, or to test every single possible interaction with that code, is much less efficient than simply having those changes and recommended practices identified (summarized) so we know what to focus on. The “list of new features” aimed at users is not quite the same thing.

Non-developers may not understand this issue and think plugin developers are being unreasonable, but as a very experienced developer, I know for a fact and from experience that the best way to coordinate a change across complex software components is with communication, not with a “handoff” of responsibility. And I am not accusing the core team of not caring about the plugin developers, because I’m sure they do… my suggestion is simply that they provide a few extra deliverables with a new release.

Yes, the release dates are too fast. Maybe the update versions require a more faster release, but new branches tend to modify everything so plugins and their authors have a hard time trying to catch up every single detail “improved” for the next branch.

Take for example the difference between 2.5 and 2.6. The changes are radical, so a lot of the plugins may break up.

If you remember a way back time, 2.0 came from 2.0.1, 2.1.0, 2.1.1, 2.1.2, 2.1.3 and so till 2.3.3

It’s not the WP team or the users fault. Both are wrong.

First the WP Team for launching a new branch so close to another without further testing (leaving this to other users to handle)

Second “The Users” have some fault too for installing a new branch just as it surfaces the wordpress.org homepage. You should know by now that .0 always comes buggy and you should better wait till .1 is released.

Well, this was my 50/50 fault giver xD

Silla!

Still in all, by what I see, the biggest mistake made about the release schedule is attempting to force it into a rigid shape. Although some set pattern of releases should be kept in mind the actual schedule should remain flexible in nature. If the team feels satisfied with either a milestone or a *.1 release, then don’t wait 2 weeks for the due date to roll around (normally, they don’t but…). By the same token, by leaving the schedule flexible, if the team feels uneasy about a release (no “warm fuzzies” felt)and/or they feel more testing and feedback from users is needed to just downright “Hey, this frickin’ new feature just ain’t ready…we gotta fix it or dump it but we can’t release it! Somebody make a command decision here!” can easily be taken into consideration without the pressure of a deadline hanging over their collective heads.

Yes, the “do-it-yourself’rs” will have to go along for the ride but the simple fact is that the decision to keep a WP install as up to date as possible is up to the individual user and each and every user is responsible for their respective site and no, you don’t have to be a programmer or be fluent in code to maintain your site. Just be savvy enough to do your homework before upgrading to a major new release.

FWIW - I learned from another source today that Matt actually did provide an advance copy of the update to WP to the plugin developer, as well as provide a fix that just has not been committed as of yet. This completely changes the context so my previous comments on the matter are effectively null and void, as it sounds more and more like WP did everything they could with PP to keep things humming. Thanks though for providing this venue for users, programmers, and developers to share and expand the knowledge base. Regards,

Jason

I don’t want to get to know you that well. Haha.

There is also now a facility to install plugins directly from the WordPress repository, plus delete plugins, all directly from within the dashboard.

That facility has not yet been extended to themes, but I expect that is on the cards too.

These new features are going to make it so much easier for WordPress users to keep their product up to date.

I think if WP were to follow suit and also offer commercial support, they may be inclined to restructure their releases too.

I also miss the drag and drop widgets of 2.3.3. While you can drag and drop within a sidebar, you can no longer do it between different sidebars, which does introduce inefficiency.

However, the new system allows for more sidebars in an uncluttered view window. So it’s a trade-off.

Automattic has gone to a huge amount of trouble to accommodate users who lack technical skills by providing WordPress.com. You can even host a domain on that platform.

And I am offended by the people who wish to impose restraints on improving the self-hosted WordPress software because they’re not smart enough to figure out how to use it properly. Boo hoo. Cry me a river.