You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Niclas Hedhman <ni...@hedhman.org> on 2004/05/23 08:37:01 UTC

RT; Codebase Versioning

Gang,
This RandomThought is about leveraging Subversion for an interesting way to 
handle versioning.

* * * Background * * * 
Versioning has been around as long as computers has been able to store 
programs, and over time some 'practices' has evolved, which many of us take 
for granted today.
The Dewey notation format is trying to express the compatibility between one 
version and another of the same program, and we all know how it is supposed 
to work.
alpha, beta, RC, milestones and other markers has been introduced to express 
that developmern status (albeit not "obsolete", "no longer supported", "not 
actively developed", "deprecated" and such ) of a particular version. This is 
mixing concerns.
Build Number has also been introduced by developers, either as part of the 
official version (often as timestamp) or hidden inside the compiled package. 
This is adding more mixing of concerns.
>From time to time we develop new features, or do complete refactorings, in 
separate branches, in which case we tend to add branch on top of the Dewey 
notation as well. Yet another mixing of concerns.

So instead of super-imposing concerns on top of the Dewey notation, let's 
start all over and think outside of the box.

* * * Requirements * * * 
What do we actually need, i.e. which are the concerns;
  *  Compatibility between versions.
  *  Development Status of a version.
  *  Codebase used in a version (build number & branch).
  *  Milestone target of a version.
  *  Other ? [1]

* * * Solution * * * 
If we look at the above list, there is an interesting observation to be made. 
"Version" is part of each requirement. That means that for any piece of 
versionable content, we can have a single version identifier.
Then we can "layer" other concerns on top;
  -  Version123 isCompatibleWith Version119  [2]
  -  Version123 isInStatus 'alpha'
  -  Version123 isSteppingStoneTowardsMilestone  NewCompositionModel3.4
  -  Version149 isPartOfProduct  Merlin3.3.1  [3]
  -  Version147 isExperimentalInBranch  avalon/branches/availability

So, we are talking about a simple version number uniquely identifying the 
codebase, and adding Meta-information to such version.
What I am getting at is probably not new at all, and I suspect that the 
Subversion developers have realized this already, SINCE they use a single 
unique identifier for the entire codebase in a svn repository. After all, svn 
is version control system, and shouldn't be concerned about other concerns.

That means that it won't even be necessary to 'tag' the repository when a 
Release is being made. For instance, all the content parts that has the 
meta-info  "nnn isPartOfProduct  Merlin3.3.1" are needed to put together 
Merlin3.3.1, and nnn denotes the subversion revision number to check out.

Clear?  I hope so...

* * *  Issues to be solved * * * 
  -  This requires some type of meta information assignments to 'versionable 
content parts'. Whether this is part of the regular code base, or as 
'subversion properties' is not clear to me at the moment.
  -  Subversion commits increments the revision number, but how do I get hold 
of it. Do I need to get hold of it? 
  -  Tool support. Is it at all feasible without automating the whole 
handling, and create some tools that are easy to interact with?
  -  Revision to Meta data cross-referencing needs to be automated and 
production of human-readable form (html?), making it more accessible to 
humans.


WDYAT??


Cheers
Niclas


Notes;

[1]  I am sure there are many other concerns that are orthogonally intersected 
with the versioning, and will be realized in due time. We have been so 
pre-occupied with not making the Dewey too unwieldly, that it may not be 
clear at the moment.

[2]  Version123 -->  "Version" is indicating a versionable content part, and 
"123" a particular revision number of the entire codebase.

[3]  Product versioning has nothing to do with code versioning.


-- 
   +------//-------------------+
  / http://www.bali.ac        /
 / http://niclas.hedhman.org / 
+------//-------------------+


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


Re: RT; Codebase Versioning

Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:

> WDYAT??

IMO you on the right track!  Have been thinking along the same lines for 
a few months now.  What's not too clear to me is the mechanisms we need 
to pull out SVN version information during a build process - but once 
that it resolved it should be reasonable to integrate that information 
across the system.

Cheers, Stephen.

-- 

|---------------------------------------|
| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |
|---------------------------------------|

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