[wp-hackers] 2.2 release

Computer Guru computerguru at neosmart.net
Fri Apr 20 06:57:49 GMT 2007

Wow, nice work Mark!

It works great on a fresh install; I'll be doing my testing from there.

Computer Guru
NeoSmart Technologies

> -----Original Message-----
> From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-
> bounces at lists.automattic.com] On Behalf Of Mark Jaquith
> Sent: Friday, April 20, 2007 7:08 AM
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] 2.2 release
> On Apr 19, 2007, at 11:43 PM, spencerp wrote:
> > Awesome! I'll SVN CO the 2.2 branch on a sub domain on
> > spencerp.net, and then starting testing/looking for issues. Let's
> > try and get this puppy to the public asap! ;) :)
> Yeah, which reminds me to remind you all: don't expect to be able to
> SVN switch from a post-tags /trunk/ install and still have this
> work.  So for people who have test blogs and would like to help us
> get 2.2 out the door in a timely fashion, drop your tables and start
> with a fresh install, or do an SVN up from 2.1.3 or earlier.
> As for people who have been running trunk on their main blogs, I'm
> sure someone will write a conversion script to get you back to pre-
> tag state... you can just keep those blogs frozen on the current /
> trunk/ revision until such a script is available.
> And as a way of documenting my procedure for posterity (and maybe for
> a future version of me doing a web search), this is how I cranked out
> that patch:
> (1) work backwards through http://trac.wordpress.org/log, looking for
> patches that have to do with the feature
> (2) click the link to look at the changeset
> (3) right-click the "Unified diff" link at the bottom and select
> "Copy link location"
> (4) $ wget -O patch.diff <PASTE>
> (5) $ patch -p0 -R < patch.diff
> (6) correct any paths in the patch (for instance, I had to remove /
> trunk/)
> (7) note any failed chunks, and manually correct
> (8) repair any collateral damage (patches with non-tag fixes that
> went in with a tags change)
> (9) repeat until the feature is removed
> If the majority of commits had been non-tag commits, I would have
> reverted to the pre-tags version and re-implemented those non-tag
> patches, but since there were a lot of non-tag commits, I decided to
> target tag commits for removal.
> --
> Mark Jaquith
> http://markjaquith.com/
> Covered Web Services
> http://coveredwebservices.com/
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list