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

[Felipe Piccolini]

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
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev


Felipe Piccolini M.
felipe.piccolini at bluesoft.cl




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070202/61ae598d/attachment.html