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