[theme-reviewers] Why can't theme authors have a second version of a theme?

Trent Lapinski trent at cyberchimps.com
Sat Sep 27 04:50:14 UTC 2014


We were actually planning on doing this with most of our themes, because it makes perfect logical sense from a technological and branding stand point. It’s good, smart business practiced by almost every company in America, including WordPress, and Automattic.

There is nothing wrong about what we are purposing.

Every theme author should have the right to use their own branding for successful themes and plugins. 

The TRT should not have the right to take away our ability to brand. The TRT is not the branding police and this rule is wrong.

People have been using our themes for over 3 and a half years, they trust them, and we have several established brands including iFeature, Responsive, Eclipse, and many others.

If we want to release iFeature HD, or iFeature Retina, and differentiate niche features from a core product line, who does this hurt?

It assures that users who know our brands find our products in an ever growing sea of themes.

What if we want to release a series of iFeature based child themes with different unique identifiers?

Why should we be forced to abandon our brands and our product lines for a poorly conceived guideline?

This guideline is over reaching, and never should have been put into effect as it is in the first place.

We cannot control others perception of value, we’re simply trying to release the next version of our theme without having to break anyones website. Unfortunately, because our theme is supposedly valuable shouldn’t change the problem we’re facing or the solutions to this problem.

--Trent Lapinski
CEO of CyberChimps Inc.
Twitter @trentlapinski
Skype: mobiletrent

On Sep 26, 2014, at 9:30 PM, Philip Arthur Moore <philip at pressbuild.com> wrote:

>> Again, we're not trying to pull one over on anyone, we're trying to do what
>> makes the most sense for protecting end-user.
> Simple solution: upgrade V1 to V2 while also maintaining backwards
> compatibility. This can be achieved in any number of ways, but the
> primary point is that V1 users are given an opportunity to switch over
> to V2 without breaking anything until they are ready to upgrade to the
> new markup.
> Long term, the best thing for you to think about is Responsive as
> Responsive. Not a version number. Who's to say the same issue won't
> happen 1 year from now when you've decided to release Responsive III
> into the repo?
> Unfortunately you have chosen a development road that is in
> disagreement with the guidelines of the repo. You should either a)
> change the name or b) provide a legit upgrade path for users while
> maintaining backwards compatibility.
> It shouldn't matter how much time you've already put into this. Wrong
> is wrong. Things have been pulled from Core just before release that
> have taken hundreds of man hours because they were wrong.
> I don't like typing because sometimes my tone can come across as
> harsh, so please don't take it that way. It's just somewhat annoying
> that this is even a conversation, when the main reason this is an
> issue is because the term Responsive is valuable to your business,
> which has absolutely nothing to do with maintaing proper development
> practices for WordPress, themes, and the repo.
> _______________________________________________
> theme-reviewers mailing list
> theme-reviewers at lists.wordpress.org
> http://lists.wordpress.org/mailman/listinfo/theme-reviewers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wordpress.org/pipermail/theme-reviewers/attachments/20140926/bc774f8c/attachment.html>

More information about the theme-reviewers mailing list