[buddypress-trac] [BuddyPress Trac] #6642: BP Template Versioning

[buddypress-trac]

#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 r-a-y):

 This is kind of genius, @imath.

 Sorry for only reviewing this now.  Here are my thoughts:

 .changelog.php:

 - Marking changesets as important requires manually updating the
 `.changelog.php` file.  If we are only concerned about important
 changesets and since we would still need to mark important changesets
 manually, do we need to parse every template changeset for a verbose
 changelog?

 BP Templates Checker plugin / Template docblock:

 - Using the `get_file_data()` function to parse out `@internal`'s `Edited`
 and `Created` version = fantastique!  Very smart! :)
 - I like the use of the `@internal` tag.  Is there a reason why two `}}`
 characters are used to close the `@internal` tag instead of one?  Is it
 for parsing purposes?
 - Either `@internal` or `@template` is fine with me.
 - Themes that have previously overriden bp-legacy template parts will need
 to manually add the `@internal` header to their template parts.  This is
 probably a stumbling block.

 changelog.json:

 - I do echo DJPaul's concerns about shipping a `changelog.json` file into
 core.  Couldn't we add it to the `/tags/xxx/` or `/branches/xxx/` repo and
 omit it from release?  When the `Templates` tab fetches the changelog, it
 fetches the JSON file from Trac instead?  If we are packaging the file,
 perhaps format it as a HTML file instead so it functions okay if someone
 is just looking at the file? (Yeah, I know this is more work...)

 - I also love the automation about parsing our own internal commit logs
 for the changelog.json file.  DJPaul mentions that this is only in
 English; I do not think this is a big deal if we are only exposing this
 via `WP_DEBUG` (meaning only developers would be checking this out).
 Localizing these commit messages would mean adding the changelog into core
 as a PHP file, which means more work for translators and also that this
 file could grow over time.  So I am kind of against localizing the
 changelog.

 This is the beginnings of a great tool, imath!  I'd be okay with this in
 2.4 if we can address some of these concerns.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6642#comment:11>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac