<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">I was thinking the same about packages... as I see it (IMHO). You are right about not versioning packages, but just rules.<DIV>versioning rules and label em with draft, revised, prod, etc. is enought to author that. Packaging is a total diferent process</DIV><DIV>in the workflow of versioning rules to put on production, so when a user edited, and finished (revised to prod state) a rule</DIV><DIV>or a group of rules (marked in categories as u implemented) then organize those rules in a package is a step to prepare</DIV><DIV>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</DIV><DIV>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,</DIV><DIV>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</DIV><DIV>the user can check that package, get history of deployments and then link the package to the rules stored on the repo of rules.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If he wants to make a change starting from the package "saved" he can get the package snapshot and edit it including new</DIV><DIV>version of rules or something like that.... or add/remove rules, etc. If he wanna do another one he must pick up rules from</DIV><DIV>repository (organized in a context-categorized way) and rapidly make another package which can o cant be as the one stored before.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I hope you can see that I agreed with the c) point :)</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><DIV><DIV><DIV>On 02-02-2007, at 3:04, Michael Neale wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite">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.<DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">_______________________________________________</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">rules-dev mailing list</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</A></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><A href="https://lists.jboss.org/mailman/listinfo/rules-dev">https://lists.jboss.org/mailman/listinfo/rules-dev</A></DIV> </BLOCKQUOTE></DIV><BR><DIV> <SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><DIV><SPAN class="Apple-style-span" style="text-decoration: underline;; -khtml-text-decorations-in-effect: underline; "><SPAN class="Apple-style-span" style="-khtml-text-decorations-in-effect: underline; "> </SPAN></SPAN><DIV><FONT class="Apple-style-span" size="3"><SPAN class="Apple-style-span" style="font-size: 13px;"><B style="font-size: 13px; font-weight: bold; "><SPAN class="Apple-style-span" style="font-size: 13px; font-weight: bold; ">Felipe Piccolini M.</SPAN></B></SPAN></FONT></DIV><DIV><A href="mailto:felipe.piccolini@bluesoft.cl"><SPAN class="Apple-style-span" style="color: rgb(0, 0, 238); -khtml-text-decorations-in-effect: underline; ">felipe.piccolini@bluesoft.cl</SPAN></A></DIV><BR class="khtml-block-placeholder"></DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR class="Apple-interchange-newline"></SPAN> </DIV><BR></DIV></DIV></BODY></HTML>