[buddypress-trac] [BuddyPress Trac] #6642: BP Template Versioning
buddypress-trac
noreply at wordpress.org
Tue Oct 6 20:52:19 UTC 2015
#6642: BP Template Versioning
-----------------------------------------+------------------
Reporter: hnla | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 2.4
Component: Appearance - Template Parts | Version:
Severity: minor | Resolution:
Keywords: dev-feedback |
-----------------------------------------+------------------
Comment (by hnla):
Great comments @boonebgorges & @DJPaul thanks guys - I can respond to some
imath better for others.
>hnla does a good job of outlining the benefits.
It must be said though with a lot of collaboration from imath in preparing
ticket and bpdevel post.
>Putting a version history/changelog in the template files is a good idea
regardless of anything else.
In many ways this was partly the thought here, however it's eventually
used / extended the principle here is a good one and if we only get all
the templates docblocked for 2.4 it'll be a great start.
Yes the changelog is somewhat verbose, personally I tend to like the
verbosity, the level of detail, however it's a good point in maybe not
showing the minor changes.
Linking to changesets rather than changelog? yes can see the point, as for
codex page I did set up a section a while back to list specific template
changes by release version showing the changes required. I defer to Imath
for what's reasonable or possible to link to.
>let's do a dismissable admin notice "Hey, some of your templates are out
of date. Enable WP_DEBUG to see details, or contact your theme developer."
Think that's a sensible idea. WP_DEBUG is definitely the switch to avoid
alarming non techie users and messages if seen by them must not alarm or
suggest their site is about to collapse.
Questions on docblocks are best left to yourselves to ponder I thought
@internal seemed a logical choice.
>how it will help "us" core developers in future
I think in the sense that we are secure in the knowledge that we're
directly imparting the changes, and developers are far less likely to miss
some new feature/ important change.
>What happens if I don't want to, or can't? Can/should I be able to
dismiss the errors?
Don't then! :) Only developers will see these so we assume they can deal
with the changes. These are not necessarily errors though, however a
means to dismiss them? perhaps not a bad idea, although updating their
template version stamp would do this, or simply ignoring the tab, I think
as it's seen vis WP_DEBUG that developers would deal with updating their
overloaded templates.
>How (do I make that change?)
When we have finalised where to link to they will have examples of what to
change/update and we'll make things clear in those lines of text before
the template version notices start.
>Therefore, have you considered the different importance of changes?
Yes and no, this is a first but very strong draft if you like, we're
verbose in reporting all changes and maybe that's good? Aria might not be
critical or a 'feature' however not a bad thing to point out we have
improved our template with? In addition note that we do highlight what
changes we do consider are the ones important to attend to ( a better SC
will be seen in the bpdevel post when it's published)
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6642#comment:7>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list