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

[Michael Neale]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20070202/8c716009/attachment.html