[rules-dev] package and deployment versioning for repo (design thoughts)

Hi All. Been working on package versioning etc, and it was really confusing me and doing my head in. 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). So - what I propose is the following: a) the ability to "status change" all the assets in a package in one hit b) changes to package "meta data" such as description are not versioned per-se c) for deployment, you "copy" (ie take a snapshot of) a package to a deployment "area": eg say we have a package foo.bar we then take foo.bar, set the status to "PROD" and then copy it to /deployments/foo.bar/DeploymentLabel eg Date... 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. 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??). Please share your thoughts, this is the parth I am going down for now. Its taken me too long to get to this point ;) 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 ! Michael.