Comments interspersed...<br><br><div class="gmail_quote">On Mon, Aug 2, 2010 at 11:42 AM, Bruce Wampler <span dir="ltr"><<a href="mailto:brucewampler@gmail.com">brucewampler@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
A note about 2010 Weaver V 1.2<br>
<br>
This new version of my theme has been in the queue for over 3 weeks now (ticket 366). It<br>
is a "child" theme of Twenty Ten (actually, a "pseudo-child" since in included all the<br>
code from Twenty Ten as well as its own code.)<br>
<br>
Since I submitted V 1.2, Twenty Ten released Version 1.1 which had some minor fixes,<br>
but generated a couple of also minor but visible incompatibilities with the child.<br>
<br>
I just submitted 2010 Weaver 1.2.1 that includes the newest Twenty Ten 1.1, and<br>
fixes the incompatibilities. The new ticket is 541. I would like to respectfully request<br>
that when the turn for ticket 366 comes up (it is just a few down at the moment) that<br>
the version 1.2.1 be used instead, and not be sent to the end of the line. This change<br>
was caused by the release of a new version of the parent.<br>
<br>
This of course again brings up the issue of handling child themes. Which versions of<br>
which parent/child themes are compatible? And after experiencing this very issue<br>
with 2010 Weaver 1.2, I believe even more that the proper way to handle child<br>
themes in the published library is to do it the way I have with 2010 Weaver - leave<br>
it up to the theme developer to included the files from the parent as well as the<br>
child in a "pseudo-child". At least then when a new parent version is published, the<br>
child theme will continue to work, even if it doesn't take advantage of whatever<br>
is new in the parent.<br></blockquote><div><br></div><div>I disagree with this point. What you suggest would deprive "pseudo-child" Themes of the vast majority of their power and usefulness. </div><div>I believe what you call a "pseudo-child" Theme would be more properly termed a *derivative* Theme. I think both *derivative* Themes and *child* Themes have their place.</div>
<div><br></div><div>As for your specific issues regarding incompatibility from TwentyTen 1.0 and 1.1: without seeing all the files from TT 1.0 and 1.1, as well as your Theme's two versions, it is difficult to speak definitively. However, is it possible to code either a child or derivative Theme in such a way that it would degrade gracefully in case of up-version induced incompatibilities?</div>
<div><br></div><div>It's probably outside the scope of this mail list, but if you would like to discuss your specific Theme-incompatibility issues, I'd be happy to do so individually. I'm totally guessing, but it seems to me that we can find a way to ensure more robust compatibility, and/or more graceful degradation.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In times when there is not a very long queue for reviews, a few days probably won't<br>
matter if a new update of the child is needed. But when the queue is several weeks<br>
long, or more, and the child is based on a major theme (like Twenty Ten), I think<br>
it is fair to account for the special case of a parent's update requiring changes in<br>
the child and not bump the new version all the way to the end of the queue.<br>
<br>
And this really applies to any theme for that matter. If a theme author discovers<br>
an issue with a theme in the queue, I think the revised version should retain<br>
the original place in the queue. To do otherwise is to discourage authors from<br>
supplying the best versions of their theme. I think many authors would rather see<br>
their slightly buggy theme get reviewed as soon as possible, rather than submit<br>
a revision that could delay the release of their theme for several weeks.<br>
<br>
So rather than closing the first ticket, perhaps it should remain in the queue but<br>
contain a comment and link to the newer version. When its turn comes up, then<br>
all associated tickets can be closed.<br></blockquote><div><br></div><div>On this point, I agree. I don't think that Theme authors should be penalized for finding/fixing errors or issues with their Themes between the time the Theme is queued and the time that it is reviewed.</div>
<div><br></div><div>Perhaps we can strike some balance here?</div><div><br></div><div>Chip</div></div>