Topic suggestion for Sept 10 chat?
Topic suggestion for Sept 10 chat?
Recent comments
newtonsongbird on Suggestions Kim Parsell on Core Contributor Handbook Lance Willett on We’re getting very close… Muhammad Abdi on Core Contributor Handbook Maor Chasen on We’re getting very close…
Jeffro 3:38 pm on September 10, 2009 Permalink
I’d like to know if we could talk about the way releases are handled on the development blog. Taking a look at posts in the past regarding releases, the display of information, links to changesets or the lack thereof are all over the map. I think it would be beneficial for the team to share a template to use for Release type posts on the dev blog.
One other thing I wanted to know. Why is it that typically, to upgrade WordPress you need to upload the entire package even if just a few files were changed? For those folks where auto upgrade does not work and they do not want to wait for 20 minutes to upload the WordPress package, is it safe to just upload the changed files to perform the upgrade? This ties into my first discussion point.
Jane Wells 3:46 pm on September 10, 2009 Permalink
“To share a template to use for Release type posts on the dev blog” implies that there’s a template to share, which there isn’t.
Announcement posts are written individually and tend to vary in style based on what kind of release it is and who’s writing it. Matt’s posts are chatty and highlight the headline features, Ryan’s posts are practically haikus that link to the .zip, etc. I agree it would be good to have a set of information that is included each time, though, for whichever author to check against. Not sure if this needs to be a discussion point in the chat, though… might make more sense to put together a list of items to include, post it here, and invite feedback, especially since all the announcement authors won’t be in the chat today.
There have been past releases where the announcement says you can just upload/overwrite specific files.
Dougal Campbell 3:09 pm on September 11, 2009 Permalink
I’m still drafting out a blog post with many ideas for improving (I hope) community information and such. But just a quick note of what I think about regarding a “template” for releases:
In each new feature release, there are changes in core along these lines:
And where I say “functions” you could also substitute “classes”, “files”, “action/filter hooks”, and “global variables”, really. Fortunately, the first item is most common, and the other three cases are relatively infrequent.
In order to help the third-party plugin/theme development community stay up-to-date with changes in core, I think it is very important that these changes are documented in a standard fashion. Currently, we pretty much just have to keep our eye on changes in the SVN repo and/or Trac, and hope that we don’t miss something important. I’d like to us to have a known place where one could see these sorts of internal technical changes detailed in a formal way.
Is there a way to automate it? I don’t know if there’s an existing tool for it, but at least some of it *could* be automated. It shouldn’t be hard to automate detection of new functions, classes, and files. And deprecation tagging should be easy, too. Detecting changes to existing functions could at least be partially automated, if it’s something obvious that affects the @param or @return tags in the phpdoc. Other changes (like a new global variable related to a new feature) might have to be documented manually. And of course, when I say that automating some of these things should be “easy”, I mean compared to trying to track them by hand and write it all up at release-time.
BTW, I wish I could participate in the dev IRC chats, but they take place right around the time that I’m trying to wrap up work and get ready to head home, and my family is a higher priority
scribu 5:19 pm on September 10, 2009 Permalink
For the second part, there was some discussion on downloading only changed files. Not sure if there’s a ticket on trac for it though.
Mark Jaquith 8:20 pm on September 10, 2009 Permalink
There’s a way to do this in Trac, but it’s not immediately obvious. I can share in the chat.
Dougal Campbell 8:53 pm on September 10, 2009 Permalink
It’s fine that various people do their own writeups about releases in their own style.
But I think that there could be some value to codifying/formalizing some sort of “official announcement style”, even if it is posted separately (Codex?), and merely referenced in the other announcments.
This is something I’ve been kicking around in the back of my brain for some time now, and there are hints of it in the postings I’ve made recently on wp-hackers, my own site, and in comments elsewhere, regarding the recent worm incident. I’m working on another blog post about it now.
This isn’t the place for a lengthy discussion about it, however. After I finish putting my thoughts down, I’ll post a note about it on wp-hackers, and I’d like to see some more discussion there about the pros/cons/costs/benefits of formalizing some release procedures and information.
Jeffro 9:04 pm on September 10, 2009 Permalink
Ok, guess I should get on the ball and rejoin the hackers mailing list.
scribu 8:01 pm on September 10, 2009 Permalink
What’s happening with the GSOP projects? MPTT and the Search API especially.
Alex (Viper007Bond) 8:02 pm on September 10, 2009 Permalink
Search: http://wordpress.org/extend/plugins/search/
Been using it on my blog for a while. Works great.
Jane Wells 8:14 pm on September 10, 2009 Permalink
I’m getting updates on integration from all the GSoC mentors, but doubt I’ll have them all by today’s meeting. When they all come in, there’ll be a summary post on the dev blog. Held off on posting about it so we could say what was happening with each one (as opposed to just saying they were finished).
WordPress Dev Chat For 9-11-09 6:18 pm on September 11, 2009 Permalink
[...] weeks meeting consisted of an agenda that was light to non existent. However, we still managed to find some things to talk about such as the addition of changed files [...]