Hi All.<br><br>Been working on package versioning etc, and it was really confusing me and doing my head in.<br><br>Basically, it is possible to version the package as a whole (basically "baseline") it - but this is really confusing from a users point of view. each asset (rule) is also individually versioned - so this extra layer is confusing (I can't quite work it out myself - NOT a good sign).
<br><br>So - what I propose is the following:<br><br>a) the ability to "status change" all the assets in a package in one hit<br>b) changes to package "meta data" such as description are not versioned per-se
<br>c) for deployment, you "copy" (ie take a snapshot of) a package to a deployment "area":<br> eg say we have a package foo.bar<br> we then take foo.bar, set the status to "PROD" and then copy it to /deployments/foo.bar/DeploymentLabel eg Date...
<br><br> so when we look at deployments, we see a list of packages, and under them a list of deployment/snapshots (which mean whatever you want them to). Simple - not unlike how SVN branches work. Of course, this deployment copying is completely optional. Many people will simply be happy with package level statuses, and individual versioning.
<br><br>Versioning of the "parent" package is quite confusing (eg looking through the history of package versions - it isn't easy of obvious to see what they are for or restore them anyway - AND it has no parallel with SVN or other file based version that I am aware of - perhaps in the future I will resurrect it one day??).
<br><br>Please share your thoughts, this is the parth I am going down for now. Its taken me too long to get to this point ;) <br><br>Damn this is a lot of work, but it has to be, as we don't want the end users to be sweating this stuff, it has to Just Work !
<br><br><br>Michael.