[buddypress-trac] [BuddyPress Trac] #7710: Version numbering proposal

buddypress-trac noreply at wordpress.org
Tue Mar 20 11:15:42 UTC 2018

#7710: Version numbering proposal
 Reporter:  Paul Gibbs  |       Owner:  (none)
     Type:  task        |      Status:  new
 Priority:  normal      |   Milestone:  Awaiting Review
Component:  Core        |     Version:
 Severity:  normal      |  Resolution:
 Keywords:              |

Comment (by Paul Gibbs):

 This is going to be potentially confusing, so bring your peril-sensitive

 The JWO idea is missing an identification for minor feature changes. So,
 if I can amend that for that, it ends up like:

 > MAJOR – New Feature: when there is a major feature **or incompatible API
 > MINOR – Bug Fixes: when you add scheduled bug fix **or enhancement** in
 a backwards-compatible manner, and
 > PATCH – Security: when you make security fixes in a backwards-compatible

 Now, if I take SemVer 2, and tweak the wording to represent the reality
 that a incompatible major breaking change in BuddyPress is fairly rare, it
 ends up like:

 > MAJOR version when you make incompatible API changes **or major
 > MINOR version when you add functionality in a backwards-compatible
 manner, and
 > PATCH version when you make backwards-compatible bug fixes. (**security
 fixes are backwards-compatible bug fixes**)

 At which point these are basically the same. It's just semantics. I think
 people who parse SemVer numbers won't be put-off or confused by the change
 the MAJOR Version meaning, and ditto for the folk used to something like
 WordPress' versioning numbering for the MINOR part.

 For the people who don't parse version numbers and just read them as a
 string of numbers (all non-tech people?), these sorts of change won't have
 any impact on them.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7710#comment:4>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list