Hi Peter,

On Thu, 2002-05-23 at 12:51, Peter B. West wrote:
> The full range of what I want to do with versioning I am not sure of; 
> the minimum I am sure of.  I canvassed this a short time ago.  That is, 
> to eliminate the situation where the identification of a build depends 
> on manual intervention in the build.xml file which may or may not match 
> a tag in the CVS tree, which may or may not correspond to the full set 
> of files in the release.  I am astonished that this situation is 
> tolerated, although I should not be astonished to be told that it is the 
> general condition of Ant-based builds.

Considering that *every* project has a version you would think there is
a standard and robust way of handling this.

> The first thing is to get the version information returned by the 
> Version class to match a tag.  That's easy.  Include $Name$ and $Header$ 
> in Version.java as, say, private static final String fields, and include 
> getTag() and getHeader() methods which simply return those values. 
>  Modify getVersion() to manipulate the $Name$ tag value, expressed 
> according to the convention which I have also canvassed, without 
> response, here earlier.  If there is no $Name$ value, a default version 
> string, something like "FOP.Development" (a string which could not be 
> generated from a legitimate tag) would be returned.

One situation that might need considering is when there is no cvs. For
example the source distribution. They may also want to set the version
number themselves.

> That, obviously, is fairly easy to do.  Trickier problems include:
> 
> Reporting the new getVersion() string during the build.  Done fairly 
> easily by an Ant task which simply emits the derived string to the 
> normal verbiosity stream.  Should probably involve similar labelling 
> procedures in Version.java and build.xml.
> 
> Validating that the whole source tree corresponds to the tag in 
> Version.java.  This necessarily involves the inclusion of keywords in 
> every source file of the build.  Now there's a novel idea.  Another task 
> required, and it would be useful if I could get the canonical tag value 
> back into the build somehow, as for example with backquotes in a 
> shell-based unix build process.  I don't know how to do this in Ant.
> 
> I want to look at all of these things, but clearly not all before 0.20.4.
> 
> Let me say a few words about the CVS tree.  It's not a sacred site.  It 
> has branches in order, among other things, to enable isolated 
> development.  IMHO, all individual development should take place on 
> personal branches, unless multiple developers are closely co-ordinating 
> attacks on particular pieces of code.  Make changes, find out what 
> others are up to, merge into your own branch from the trunk as 
> necessary, and when you're ready, notify everyone that you want to merge 
> back to the trunk.  Do that.  Find, and resolve with the other 
> developers any merge conflicts.  Abandon the branch.  Throw another one 
> and move on.  This tool allows such things to happen and protects 
> everybody's investment, so let's take advantage of it.  If a branch is 
> abandoned without ever being integrated into a release, so what?

That is true.
On the other hand this sort of approach does not enforce and promote
community development. In practice branches are used for version and
maintenance+bugfix or major changes and development occurs in the one
place. For unproved concepts something like a scratchpad is used. Also
this doesn't really scale with more developers.
Part of the reason can be seen from the resources available to the trunk
code. Gump provides a compile and project compatibility check. People
can grab a nightly download to check and use the latest build
(admittedly broken right now). Other developers can see the changes
directly.
I don't think protecting people from problems will lead to the solution
of those problems.

I'm sorry for the all too brief comment, I will try better next time.

> Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to