This is the official blog for the core development team of the WordPress open source project. Follow our progress with weekly meeting agendas, project schedules, and the occasional code debate.
It might already be included under “planning,” but we should talk about what’s meant by the proposal that development “take a release cycle off.”
The possibilities seem to be the following:
Just the emphasis of the active commit devs, not any formal policy about accepting patches. E.g. Peter will spend most of his WP time on the health check plugin, not trunk.
No big new features in 3.1. E.g. the Media Revolution, Rewrite Evolution, or any other significant reconstitution will have to wait until 3.2.
Nothing but bugfixes or security fixes in 3.1. I.e. 3.1 == 3.0.x.
Nothing, period, in 3.1. Trunk will skip on to 3.2 like we did over 2.4.
I was thinking that would be covered in planning.
What ever we do we need to spend a couple of meetups probably just talking about what we want to achieve. What to prioritise etc.
I was thinking about this as well. Part of the development is the community and this has always been contributors other than the “core” devs. Most of the stuff I’ve contributed in the past hasn’t been on some planned list nor could it have been most of the time until I made a patch for them.
I think that if I spend the time to write the patch, test it, and do most or all of the leg work that it shouldn’t matter. I don’t want to wait 6 to 8 months for something I want to get in sooner for testing and feedback.
The longer something takes to get into WordPress, the longer it is to get feedback. Truth of the matter is that people don’t really care unless it is in or going into WordPress in terms of testing and the implementation.
As an aside, it did take around 5 to 6 months before the HTTP API went in, but it wasn’t something I was terribly concern on at that time.
Most of the HTTP API improvements are complete, tested, and awaiting inclusion into core. Rewrite improvements… well, maybe. I think the fact that I don’t like my current code as it stands now says something. I think quite a bit of work needs to be done for the router and controller improvements.
Perhaps, doing it in steps, with 3.1 include the router and have it work with the current Implementation, something that would have little to no implications for WordPress, except make it more awesome. Then with 3.2, move more of WordPress to using the Router / Dispatcher implementation.
Also, if I work on it today and tomorrow, I should have something to show at the meeting. That might be a basis for a discussion other than one I would rather not have, like for example, whether improvements need to be made. I’ve found it is easier to explain and get feedback on code rather than some abstract and, or far off concept.
Peter Westwood 10:54 am on June 19, 2010 Permalink
Planning the next few months, what are the next steps
Peter Westwood 10:54 am on June 19, 2010 Permalink
Review of 3.0 feedback – incoming ticket rate, common issues etc.
filosofo 1:09 pm on June 19, 2010 Permalink
It might already be included under “planning,” but we should talk about what’s meant by the proposal that development “take a release cycle off.”
The possibilities seem to be the following:
filosofo 1:11 pm on June 19, 2010 Permalink
I vote for #1.
Jacob Santos 8:49 pm on June 22, 2010 Permalink
I also hope that it will be #1.
Peter Westwood 1:17 pm on June 19, 2010 Permalink
I was thinking that would be covered in planning.
What ever we do we need to spend a couple of meetups probably just talking about what we want to achieve. What to prioritise etc.
Jacob Santos 8:48 pm on June 22, 2010 Permalink
I was thinking about this as well. Part of the development is the community and this has always been contributors other than the “core” devs. Most of the stuff I’ve contributed in the past hasn’t been on some planned list nor could it have been most of the time until I made a patch for them.
I think that if I spend the time to write the patch, test it, and do most or all of the leg work that it shouldn’t matter. I don’t want to wait 6 to 8 months for something I want to get in sooner for testing and feedback.
The longer something takes to get into WordPress, the longer it is to get feedback. Truth of the matter is that people don’t really care unless it is in or going into WordPress in terms of testing and the implementation.
As an aside, it did take around 5 to 6 months before the HTTP API went in, but it wasn’t something I was terribly concern on at that time.
Andrew Nacin 8:10 am on June 20, 2010 Permalink
Trac and 3.1. — Nacin
Aaron Jorbin 8:43 pm on June 20, 2010 Permalink
3.0.1 and what the backporting philosophy / policy will be (Only blockers/critical or will other bug fixes be allowed in)
Jacob Santos 8:48 pm on June 22, 2010 Permalink
For me personally, HTTP API improvements and Rewrite improvements.
Alex M. 10:18 pm on June 22, 2010 Permalink
This should probably wait until 3.1 development begins, no?
Jacob Santos 10:23 pm on June 22, 2010 Permalink
Most of the HTTP API improvements are complete, tested, and awaiting inclusion into core. Rewrite improvements… well, maybe. I think the fact that I don’t like my current code as it stands now says something. I think quite a bit of work needs to be done for the router and controller improvements.
Perhaps, doing it in steps, with 3.1 include the router and have it work with the current Implementation, something that would have little to no implications for WordPress, except make it more awesome. Then with 3.2, move more of WordPress to using the Router / Dispatcher implementation.
Jacob Santos 10:25 pm on June 22, 2010 Permalink
Also, if I work on it today and tomorrow, I should have something to show at the meeting. That might be a basis for a discussion other than one I would rather not have, like for example, whether improvements need to be made. I’ve found it is easier to explain and get feedback on code rather than some abstract and, or far off concept.