Project

General

Profile

Feature #6387

Provide versioning API in art_Framework_Core instead of art_Version

Added by Ben Morgan over 5 years ago. Updated about 2 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
Infrastructure
Target version:
-
Start date:
05/30/2014
Due date:
% Done:

0%

Estimated time:
Scope:
Internal
Experiment:
-
SSI Package:
art
Duration:

Description

The art_Version library appears to provide a single function that returns hard coded version string, presumably the current art version?

If so, consideration should be given to moving this functionality into art_Framework_Core (or similar) for coherence and simplification of the library structure.

A further enhancement would be to extend the versioning API to provide compile and runtime interfaces to query major, minor and patch numbers, plus available features.
A possible implementation is present in Chapter 8 of API Design for C++

I'm happy to supply a patch for this, plus the compile time checks, if required.

History

#1 Updated by Christopher Green over 5 years ago

  • Category set to Infrastructure
  • Status changed from New to Feedback
  • SSI Package art added
  • SSI Package deleted ()

The art_Version library appears to provide a single function that returns hard coded version string, presumably the current art version?

At the moment, this is the current art version.

If so, consideration should be given to moving this functionality into art_Framework_Core (or similar) for coherence and simplification of the library structure.

The functionality is in its own library precisely so it can be at the bottom of the dependency chain and be used by all the libraries above it where appropriate.

A further enhancement would be to extend the versioning API to provide compile and runtime interfaces to query major, minor and patch numbers, plus available features. A possible implementation is present in Chapter 8 of API Design for C++.
I'm happy to supply a patch for this, plus the compile time checks, if required.

We could certainly see a use case for version by major, minor and patch numbers, but we would need to understand use cases and scope for, "available features." You should also bear in mind that this feature may be affected by efforts to individually version user plugin libraries.

If you are able to clarify the question of available features, we will bring this up for discussion in the art stakeholders meeting about wider relevance and general desirability of a feature like this.

#2 Updated by Ben Morgan over 5 years ago

Christopher Green wrote:

If so, consideration should be given to moving this functionality into art_Framework_Core (or similar) for coherence and simplification of the library structure.

The functionality is in its own library precisely so it can be at the bottom of the dependency chain and be used by all the libraries above it where appropriate.

Analysis of where the art/Version/GetReleaseVersion.h header is actually used, and art_Version is linked, shows that the inclusion only occurs in art_Framework_Core, art_Framework_EventProcessor, art_Framework_IO_Root, art_Utilities and art_Version itself. The only libs that appear to explicitly link to it are art_Framework_Core and art_Framework_Principal (which doesn't even use it), the others appear to rely on transient linking to art_Framework_Core or otherwise. Hence, the framework core really defines the access point for versioning info anyway.

If it's needed in plugins, or layers above the core framework then could there be a "version service"? That's assuming my understanding of services as points of contact for standard functionality.

A further enhancement would be to extend the versioning API to provide compile and runtime interfaces to query major, minor and patch numbers, plus available features. A possible implementation is present in Chapter 8 of API Design for C++.
I'm happy to supply a patch for this, plus the compile time checks, if required.

We could certainly see a use case for version by major, minor and patch numbers, but we would need to understand use cases and scope for, "available features." You should also bear in mind that this feature may be affected by efforts to individually version user plugin libraries.

If you are able to clarify the question of available features, we will bring this up for discussion in the art stakeholders meeting about wider relevance and general desirability of a feature like this.

A typical use case for a getFeature type function is when the framework provides optional functionality that isn't encoded in a standard version number. One example from image processing is support for different formats, e.g.

if (myapi::hasFeature("JPEG_SUPPORT")) {
  … do something with jpeg…
} else {
  … do something default …
}

For art this may not be necessary if everything is already compiled in.

#3 Updated by Kyle Knoepfel over 4 years ago

  • Target version set to 521

#4 Updated by Kyle Knoepfel about 2 years ago

  • Target version deleted (521)


Also available in: Atom PDF