jmcclure

Well, yes. There is info in that thread. Basically, someone whose signature labels him as a Quality Assurance Lead basically stated or implied the following info:

• There is no tag for 2.1.3.
• The 2.1 branch is “mostly harmless” if it is pulled at the time of a release.
• However, the 2.1 branch represents active development (in other words, they can’t promise anything).

So, yes. That qualifies as info, but it’s not particularly helpful info. Those of us who use svn to maintain our installs would like to update to 2.1.3 to protect ourselves against the vulnerabilities addressed in that version. However, none of this info tells us how to do that.

It’s puzzling to me that a “Quality Assurance Lead” acknowledged this and yet there’s still no tag. Is it a matter of there being no one available right now with the appropriate privileges to create the tag?

I’m also curious about something else. The subversion repository is the “home” of the code, right? If so, it would seem to be the appropriate procedure to tag subversion first, then release the tarball using a checkout from that tag. If the tag is added after the fact, isn’t it harder (or at least more work) to make sure that the version tagged in subversion matches what was used to build the tarball?

I’m trying not to be insulting here. I’m willing to admit there may be something here I don’t understand. However, we’ve now seen at least two occasions (this one and the 2.1.2 release) where the announcement and tarball went out before subversion was tagged. Admittedly, 2.1.2 was a non-issue for those of us who use svn (2.1.1 in subversion was never broken).

So, I guess my major points are:

• Tagging subversion in a timely fashion is important, because many people use svn to update production installs.
• Not tagging before the announcement is frustrating.
• There are users right now waiting on the 2.1.3 tag in order to update their installs.

I figured it out. My site has “register_globals” turned off, and whoever wrote edit.php left out the little snippet at the top that registers the variables submitted in the URL. It’s on a lot of the other pages (look for code that uses an array called “wpvarstoset”). I’ll post a complete patch for this once I’ve had time tonight to make sure it’s complete.
People on sites where “register_globals” is on won’t see this problem.