matters as we have to commit each patch twice. I wanted to create the branch as soon we release a 'release candidate'. Talking of which, should we release another beta (beta 5) or should we go straight to a release candidate?
+1 for beta 5. I don't see how this can be a release candidate when the first page of the upgrade system still spits out 2-3 warnings and (as of two days ago) the JS upgrade isn't working - comes up with an error pop-up (switching JS off solves the issue). Coupled with the "node/locale search" issue that chx is working on and stuff like "deleting user cripples nodes", "taxonomies are lost on revert" etc. there is enough of a case IMO for this not to be a RC (yet). I'm not sure what the yardstick is, but IMO these are all serious breaks in functionality.. Moreover, the above are only the issues *I* am immediately aware of. There very likely are more. I think it might be worthwhile to also consider the following (by no means conclusive, but perhaps indicative?) stats: Issues marked b4 = 68 Issues marked b3 = 52 Issues marked b2 = 36 Issues marked b1 = 25 The above include active, patch, fixed and closed. My 10p, -K P.S I'm assuming here that "Release Candidate" indicates a feature complete release which the developers (after *rigorous* internal/beta testing) have deemed to be good enough for public release, but are inviting feedback from production sites..