• State Verified Answer
  • Replies 3 replies
  • Subscribers 48 subscribers
  • Views 1597 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
×
Parents
  • 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.
Reply
  • 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.
Children
No Data