avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: Proposal: Versioning
Date Mon, 05 Apr 2004 13:27:21 GMT
Stephen McConnell wrote:

> Ok for X.Y.Z assuming we put in place a streamlined release process, and 
> on the presumption that we think about product update management based 
> on dewy decimal evaluation.
> Not OK with odd/even semantics.
> An important aspects here is that merlin cli and unit versions are 
> decoupled from model version (i.e. version 3.3 of cli and unit can 
> handle anything within the scope of a minor version change relative to 
> the avalon repository version).
> Some additional functionality is needed to deal with product 
> synchronization - e.g. a command line option enabling updating of 
> merlin.properties to reflect the latest kernel release.  The key point 
> is that the version of cli and unit can remain stable but the 
> implementation can evolve frequently.
> Cheers, Stephen.

Hmm. The seeming product fragmentation would seem to present a problem as
far as confusing users.  For example, the user has to know that Merlin CLI
version 3.2.* will work with Merlin Model 3.4.*, but not Merlin Model 3.0.*,

This is just a contrived example.  Consider the example of the "big software"
releases.  Instead of having different version numbers for all of the pieces,
there is one big version for everything in a release.  When you buy Office XP
you get all the pieces that are current to Office XP--whether some pieces have
changed or not from the previous version.  The "whole" is Offics XP.  This is
understandable to users, and far less confusing than say the way the Linux
Kernel and module management library work.  The user has to know from the docs
which version of the module management library works with which kernel.  Usually
the numbers are pretty different.

That can lead to some confusion.  It is part of the reason why it is not popular
to build a full linux system from scratch.  That, and you have to know which
versions of your apps will work with what version of the C library, etc.

I would encourage a versioning system that makes it as easy for the user as

For example, the way labeling works with version control systems means that when
we cut a 3.3 release, we can mark all code as 3.3, even if it has not changed
since the last release.  That would mean that even if the Merlin CLI hasn't
changed and the kernel has, it could be re-released with matching version
numbers to cut down on potential confusion.  I am not adamant, but I think it
would be wise to consider that.

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message