0 Replies Latest reply on Apr 21, 2015 12:46 PM by brmeyer

    Design discussion: Proper support for artifact versioning


      I'd love some feedback on this.  One important item that I'd like to include in 1.0.0.Beta1 is proper, OOTB versioning support for artifacts.  That obviously includes additions to the UIs, but those are (for the most part) cut and dry.


      The tricky part will be how this is managed on the server.  In addition to adding and emphasizing a "version" field, we'll also need to figure out how to define "grouping".  Ideas:


      1. Automatically group artifacts that have identical types and names (and make use of other metadata, such as Maven GAV, if available).  The primary drawback here is conflicts.  It might be a mistake to try and enforce unique names, but it is possible.
      2. Force new versions to be created by using the current version as a starting point (ex: "Import New Version" button on an artifact's details view).  This could be stored in a few different ways:
        1. Store artifacts in a "linked list" fashion.  Each new version would have a reference to the previous.  This would be easy to implement, but it certainly widens the tree.  Further, I'm worried about horizontal-scaling and performance for deeply-versioned artifacts.  Even worse, to display the entire set of versions would require traversing the list and querying-by-reference for every link.
        2. Change the JCR structure.  Each primary node effectively becomes the parent/root for the entire set of versions.  Each version of the artifact, including the first, becomes a child of that root.  This would provide easier queries and most likely better read performance, but would be somewhat more complicated to implement.  Further, however unlikely, it would become one more thing to include in a migration path, should someone need it from 0.6/0.7-1.0.

      Any opinions?