API version

[revisionfx]

Open Effects Proposal for Standard Change

Please read the contribution guidelines first.

Standard Change Workflow

• [X ] Create proposal as issue (you're doing this now!)
• [ X] Tag this issue with standard change tag
• Identify subcommittee: at least one plug-in vendor, and at least one host
• Discuss the idea in this issue
• Write new or updated code and doc
• Publish updates as a pull request (ideally on a feature/PROPOSAL-NAME branch)
  • Make sure that PR references this issue number to keep them in sync
  • Discuss and review code in the PR
  • Meet all requirements below for accepting PR
• When subcommittee signs off and other members don't have any further review comments,
  maintainer merges PR to master which closes PR and issue

Requirements for accepting a standard change:

• Header files updated
• Documentation updated
• Release notes added
• Compatibility review completed
• Working code demonstrated with at least one host and one plugin
• At least two members sign off
• No further changes requested from membership

Summary

We don't define explicitely the API version as a string at least anywhere. We do have GetAPIVersion but it's not clear it's being properly updated/referred to.

Motivation

Although API version should not be a conditional for compliance, it's a good practice when adding features in API to mark the version this was added with context.

Problem

Adds an explicit version string. Suggestion is to add "1.5" in ofxCore and a top level text file with sub-version, e.g. 1.5.5, for each API update. The sub-version would be used to in parallel update the wiki entry with Issue/PR number. This way a developer can see what was added since they last downloaded master and at a glance understand what matters to them.

Impact

Provides a way to source API version in non-ambiguous manner.

Documentation Impact

When you google the version displayed would be auto-accurate.

Stakeholders

All

Discussion