yep - good that someone else agrees - it was easy to implement things that way actually - and it gives heaps of flexibility.<br><br><div><span class="gmail_quote">On 2/3/07, <b class="gmail_sendername">Felipe Piccolini</b>
<<a href="mailto:felipe.piccolini@bluesoft.cl">felipe.piccolini@bluesoft.cl</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="">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></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></div><div>I hope you can see that I agreed with the c) point :)</div>
<div><br></div><div><br></div><div><br></div><div><div><div><div><span class="e" id="q_11083358c0278402_1"><div>On 02-02-2007, at 3:04, Michael Neale wrote:</div><br></span></div><blockquote type="cite"><div><span class="e" id="q_11083358c0278402_3">
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.</span></div><div style="margin: 0px;">_______________________________________________</div><div style="margin: 0px;">rules-dev mailing list</div><div style="margin: 0px;"><a href="mailto:rules-dev@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
rules-dev@lists.jboss.org</a></div><div style="margin: 0px;"><a href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.jboss.org/mailman/listinfo/rules-dev
</a></div> </blockquote></div><br><div> <span style="border-collapse: separate; border-spacing: 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-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px;">
<div><span style="text-decoration: underline;"><span> </span></span><div><font size="3"><span style="font-size: 13px;"><b style="font-size: 13px; font-weight: bold;">
<span style="font-size: 13px; font-weight: bold;">Felipe Piccolini M.</span></b></span></font></div><div><a href="mailto:felipe.piccolini@bluesoft.cl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
<span style="color: rgb(0, 0, 238);">felipe.piccolini@bluesoft.cl</span></a></div><br></div><div><br></div><br></span> </div><br></div></div></div><br>_______________________________________________<br>rules-dev mailing list
<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:rules-dev@lists.jboss.org">rules-dev@lists.jboss.org</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="https://lists.jboss.org/mailman/listinfo/rules-dev" target="_blank">
https://lists.jboss.org/mailman/listinfo/rules-dev</a><br><br></blockquote></div><br>