How about patches?

<ego>
For the love of God, would people stop calling me Angusman!
It is Angsuman folks!
</ego>

And yes a patch from WP 1.5.1.2 to WP 1.5.1.3 is available.

Yes, I too would like it to be made available by Matt’s merry bunch (takes load off me) but that’s open source. The credo of OSS AFAIU is either you make the changes yourself, like I did, or STFU because everyone is “volunteer”, so no responsibility or obligations. In commercial software on the other hand you can literally force the company to provide you with patches.

The way things are going I may not even upgrade WordPress anymore (unless they are security upgrades). I think WP is pretty much where it can go with its architecture. After this you will start seeing more look-and-feel stuff like Ajaxian goodness, draggable menus and other niceties instead of real improvement. Already 1.6 charter reads that way.

@jemmie

If everyone goes your way then all of us have to think about reinstalling Windows after deleting all the directories where Windows put its stuff (replace it with a four letter word of your choice) and install a new copy everytime they fix a security defect, in the process deleting all your settings and customizations.

Fortunately they issue “patches”.

Angsuman: please feel free to participate in the discussion as to what “real improvements” you think are necessary.

I think removing 400 lines of duplicated code in post.php is a real improvement.
I think more plugin hooks are a real improvement.
I think a robust user capabilities system is a real improvement over arbitrary user levels.

@skippy
> please feel free to participate in the discussion as to what “real improvements” you think are necessary.

I am not sure if this is the right place but here it goes.

> I think removing 400 lines of duplicated code in post.php is a real improvement.

That is really refactoring. It doesn’t help the client directly in the short term. It makes future modifications easier. As with others it also should be prioritized. Do you have unit/acceptance tests which will ensure that something will not break while doing this refactoring?

> I think more plugin hooks are a real improvement.

Is there a real strong requirement for them? Or just someone feels they are nice? You can always add tons of hook everywhere. However they also, however imperceptibly slow down rendering of the page. I think hooks should only be added to address a strong requirement. They don’t take much time to add but we shouldn’t indiscriminately go down that path.

BTW: Don’t talk caching for speed here as caching comes with its own set of problems. It renders many real-time plugins useless.

> I think a robust user capabilities system is a real improvement over arbitrary user levels.

Define robust user capabilities. What is the plan/architecture for this new system? Fundamentally what are we getting with this?

One thing I noticed is that in several places wp template tags or functions dictate visual layout. They should be separated in all places. It makes for better template creation and maintenance.

Many important functions are not documented in codex, which I often find in the code.

Several people are using WordPress around the world. Whenever there is an upgrade it affects them. Many have personalized WordPress. Any new release should keep these users in mind. Between 1.2 and 1.5 the whole templating system changed. It was a big change for many and hence many haven’t upgraded even today as you can see in the forums. And they are hence open to security vulnerabilities. A patch for their releases would have gone a long way in helping these users.

I have seen plugins break with even minor releases like 1.5 to 1.5.1. Sufficient care needs to be taken in this respect for backward compatibility.

WordPress is moving into big league. Think Big. Look at Microsoft. They test new releases with popular software of their platform before releasing them. WP developers should similarly test popular plugins (need not be perfect list and yes mistakes can happen) with every new release. Much of it is grunt work but that’s software development. It is not always about doing the coolest thing.

Themes break everywhere with new releases. Why? We need to find out.

Part of the problem is that there is no official guidelines which says what to do and what not to do in theme development. You should think about compliance checking.

WordPress developer community should focus on perfecting existing functionality more than adding new goodies. People are still facing issues with pingbacks and trackbacks. I know them, fixed them in my blog, couldn’t find time yet to release them as plugins. Another reason is that they shouldn’t be plugins in the first place but part of core code.

WordPress needs to publish its architecture. Serious re-factoring needs to be done in places.

WP community should issue patches, especially for security upgrades. Despite the strength of plugin architecture, expect people to modify code. The community should reasonable accomodate them and not just provide blanket statements like it will be tougher for those who modify etc.

I think the above should have higher priority over ajaxian niceties and draggable menus.

> I think removing 400 lines of duplicated code in post.php is a real improvement.

That is really refactoring. It doesn’t help the client directly. It makes future modifications easier. As with others it also should be prioritized. Do you have unit/acceptance tests which will ensure that something will not break while doing this refactoring?

Removing duplicated code does help the client directly, in several ways. It slims down the single download archive a bit. It makes posting and editing use the same code, and therefore provides a unified workflow, as opposed to the previous bifurcated one for posting versus editing.

I have no unit or acceptance tests. If you have some, please submit them.

> I think more plugin hooks are a real improvement.

Is there a real strong requirement for them? Or just someone feels they are nice? You can always add tons of hook everywhere. However they also, however imperceptibly slow down rendering of the page. I think hooks should only be added to address a strong requirement. They don’t take much time to add but we shouldn’t indiscriminately go down that path.

Yes, there is an identified need for new plugin hooks. People are looking to do more and more with WordPress, including some (weird) integration with other systems. Plugin hooks facilitate these integrations without requiring users to modify core code.

Further, the core WordPress developers have repeatedly stated that the WordPress core should be kept as slim as possible, focusing on core functionality. Non-core features should be implemented in plugins. So far, this has worked well.

Plugin hooks are being added for plugin (de-)activation, user creation and deletion, and more.

BTW: Don’t talk caching for speed here as caching comes with its own set of problems. It renders many real-time plugins useless.

I said nothing about caching.

> I think a robust user capabilities system is a real improvement over arbitrary user levels.

Define robust user capabilities. What is the plan/architecture for this new system? Fundamentally what are we getting with this?

I invite you to subscribe to the hackers mailing list, where you can monitor — and participate in — the discussions surrounding the user capabilites system.

One thing I noticed is that in several places wp template tags or functions dictate visual layout. They should be separated in all places. It makes for better template creation and maintenance.

Many important functions are not documented codex, which I often find in the code.

Please submit patches for these items. If you have improvements, please share them, instead of complaining that the two core WordPress developers didn’t code things the way you would have.

Several people are using WordPress around the world. Whenever there is an upgrade it affects them. Many have personalized WordPress. Any new release should keep these users in mind. Between 1.2 and 1.5 the whole templating system changed. It was a big change for many and hence many haven’t upgraded even today as you can see in the forums.

Anyone who edits (or “personalizes”) core WordPress files is taking it upon themselves to maintain their revisions across upgrades. This is true in any Open Source system in which a user makes changes. The core system cannot be made to accomodate all users’ modifications. This is entirely up to the user.

I have seen plugins break with even minor releases like 1.5 to 1.5.1. Sufficient care needs to be taken.

Please address your concerns to the plugin authors. The core WordPress developers cannot be held responsible for plugin breakage.

WordPress is moving into big league. Think Big. Look at Microsoft. They test new releases with popular software of their platform before releasing them. WP developers should similarly test popular plugins (need not be perfect list and yes mistakes can happen) with every new release.

Plugin developers need to test their own plugins. It is unreasonable to expect the core WordPress developers to test even a smattering of the available plugins, many of which the core developers do not use.

Themes break everywhere with new releases. Why? We need to find out.

Part of the problem is that there is no official guidelines which says what to do and what not to do in theme development. You should think about compliance checking.

Please help us write the documentation necessary. Please spend time with us in #wordpress-docs, agonizing over how best to articulate complex concepts to new users without insulting advanced users.

WordPress developer community should focus on perfecting existing functionality more than adding new goodies. People are still facing issues with pingbacks and trackbacks. I know them, fixed them in by blog, couldn’t find time yet to release them as plugins. Another reason is that they shouldn’t be plugins but part of core code.

Instead of writing plugins to solve these problems, please submit patches to the core application.

WordPress needs to publish its architecture. Serious re-factoring needs to be done.

Please submit patches to help expidite your refactoring suggestions.

WP community should issue patches, specially for security upgrades.

Thank you for your volunteer effort in this regard so far. I encourage you to continue to satisfy this need for others.

Despite the strength of plugin architecture, expect people to modify code. The community should reasonable accomodate them and not just provide blaket statements like it will be tougher etc.

How do you propose we support poeple who make changes to the core files? If you’re customizing core files, then you should keep track of what you’ve changed, and why. Before upgrading, you can compare the last-modified versions of your files to the available source code. Or, if you’re handy with diff, use that.

WordPress, as a project, does a lot to make the code available to the people who want it. We, the support volunteers, have done our best to support as many people as we can. If you make modifications to core files, or if you use an unstable un-released development version of WordPress, you should expect challenges. That’s just the way it’s going to be.

I think the above should have higher priority over ajaxian niceties and draggable menus.

I happen to agree with you, but not everyone does.

This is Free Software. The two core developers do this because they want to. It is entirely their perogatvie to focus on the development aspects that give them the most pleasure.

I made a modest effort to propose something other than the draggable interface. I invite you to do the same.

Thanks for your comments. For the vast majority of releases many files change, things are moved around, things are removed, and generally it would be a waste of our time and yours to provide an archive of just the changed files. People using such an archive would be more prone to make mistakes when upgrading. It is highly unusual that a release only has 4 changed files, and that’s because of the extraordinary circumstances surrounding it. In the future if we have another highly unusual release when almost nothing changes, we may provide an archive file like you suggest, but in general we like to keep things consistent from release to release.