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

[Michael Neale]

yep - good that someone else agrees - it was easy to implement things that
way actually - and it gives heaps of flexibility.

On 2/3/07, Felipe Piccolini <felipe.piccolini at bluesoft.cl> wrote:
>
> 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
>
>
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070204/45d41d05/attachment.html