newformat format change
John A Meinel
john at arbash-meinel.com
Fri Sep 30 17:06:21 BST 2005
Andrew S. Townley wrote:
> I don't know if you will think this is relevant or not, but we're doing
> a lot of work with versioning of XML data elements and how it should
> work. What we've come up with is a set of guidelines so that it can be
> done sensibly (at least for us).
>
> The guidelines can be found here: http://sdec.reach.ie/rigs/rig0006.
>
> Whatever way you decide to add version information, it needs to be
> thought out pretty well or it'll become a royal pain to maintain/process
> going forward.
>
> Hope this helps,
>
> ast
On a brief glance, it looks like this is much more complex and involved
than I think we want to let bzr get. For instance they make the statement:
Versioning is a complex subject. So complex that one common approach
to handling it is to simply allocate fixed version numbers to entire
systems. For example, version X.X of an accounts system or version Y.Y
of an application server.
This simple sort of versioning only works well in tightly coupled
systems, i.e. systems that are built and deployed as monolithic
“releases”. In a monolithic release scenario, developers have full
control over all end points and all message exchanges and can thus
ensure that all components have been upgraded to conform to new data
models, or new business logic.
The more loosely coupled the system, the more problematic such a “big
bang” approach to versioning becomes. In the context of the PSB,
services will be developed by independent entities over time and will
be deployed and evolved in a highly autonomous fashion. It is not
feasible to shut down the PSB, upgrade all services and redeploy them
in a “big bang” release. Version control on the PSB needs to be much
more granular, evolutionary and non-disruptive.
I would argue that the bzr versioning probably does fall into the
"tightly coupled system" and thus doesn't need to really complicate things.
But it still could be a good read, I'll look it over.
John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050930/bf94f5d1/attachment.pgp
More information about the bazaar
mailing list