• State Verified Answer
  • Replies 3 replies
  • Subscribers 50 subscribers
  • Views 2346 views
  • Users 0 members are here
Options
Related

Is there a way to determine version sequence without assuming that version 2 will follow version 1?

Adam Elkins

When querying architect through the API for a list of publications, is there a way to determine what version precedes a given object without extrapolating this from the version number and assuming version 2 follows version 1? I am looking for something such as a parameter on a specific version of a publication that says version X precedes it. Or is there some object that defines all of the versions that a given object has and what the sequence of those versions is?
Rate translation
×
Suggest better translation
×
  • 0

    Hi Adam,

    The VERSION field value typically follow a format that can be used to order them. This is what the publication manager uses for example.

    As alternative you can use the creation time of the version element in the system.

    The CREATED-ON field on the version level represents this value.

    This way you order based on the timeline.
  • 0
    Hi Adam,
    Replying in an old thread here...You can create branches and versions thereof to an arbitrary depth (as far as I know there is no limit). Suppose you have a publication with version 1.1.2.1.2. It is easiest (IMHO) if you read this sequence backwards: "version 2 of branch 1 of version 2 of branch 1 of version 1". Also let's assume there is a version 2 of this same publication. It is not possible to tell, without looking into the actual history of the publication object, which version - 1.1.2.1.2 or 2 - was created first. If we look at it from a timeline perspective, neither case is more logical.

    Granted, in most cases deep branching is avoided, and you'd be correct in assuming that version 2 was created first. Then at some point there was a need to release an update to version 1 and therefore it was branched. I guess that is the most common scenario. Still, an organization could have business rules affecting version management. For example, suppose version 1 of a publication was tied to a given product release, and when the time came to create a maintenance release of that product, a branch (1.1.1) of the publication object would be created (even if version 2 did not exist), because a rule existed that dictated that "major" versions be created only when there is a new product release.