I was thinking the same about packages... as I see it (IMHO). You are right about not versioning packages, but just rules.versioning rules and label em with draft, revised, prod, etc. is enought to author that. Packaging is a total diferent process
in the workflow of versioning rules to put on production, so when a user edited, and finished (revised to prod state) a rule
or a group of rules (marked in categories as u implemented) then organize those rules in a package is a step to prepare
a rulebase in a context to use in production, so when a user package rules he is thinking in use them as a group oriented
exclusively to use in a context (I think I already wrote this... lol) and the state of rules should be "prod" picked from the repo,
so build this "package" and take a snapshot to keep in a diferent-context repo is enought and is the way to do it (IMHO). So
the user can check that package, get history of deployments and then link the package to the rules stored on the repo of rules.
If he wants to make a change starting from the package "saved" he can get the package snapshot and edit it including new
version of rules or something like that.... or add/remove rules, etc. If he wanna do another one he must pick up rules from
repository (organized in a context-categorized way) and rapidly make another package which can o cant be as the one stored before.
I hope you can see that I agreed with the c) point :)
On 02-02-2007, at 3:04, Michael Neale wrote:
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._______________________________________________
rules-dev mailing list