> -----Original Message----- > From: Keiron Liddle [mailto:[EMAIL PROTECTED]] > Sent: May 24, 2002 6:29 AM > To: FOP > Subject: Re: build changes > > 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.
Ant is a cross-platform (by virtue of Java and XML) makefile system, basically, optimized for Java projects. Which is not new information. Sometimes we all lose sight of the fact that that is all it is. I have yet to do anything with Ant that I couldn't have done with a standard makefile; it just happens that Ant is easier to use for complex Java projects. Ant imposes no standards for versioning or configuration management. That would be well outside the scope of the tool. What it does provide are useful tasks for simplifying whatever versioning and CM a team decides to employ. Apart from open-source use of Ant (mainly with FOP) I have used Ant in real-life for over 2 years. At one company the versioning and CM was based on IEEE, so we tailored our buildfiles to do that. There we used CVS. At my current place of employ, Hummingbird, we use Ant with VSS and our own versioning standards - our buildfiles are tailored to support _that_. And Apache projects are different yet again. I don't find it unusual or objectionable that the version information is not automated. If we did regular builds that would be a candidate for automation, certainly, but we don't (Gump does, admittedly, but _we_ don't). Finally, I think it would be reasonable to automate labelling (tagging) in conjunction with an actual release. But overall I don't think things are that bad. [ SNIP ] > > > > 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 tend to agree with Keiron on this, Peter. You're right, the CVS tree is not sacred, but the development model you advocate is not the usual one. For the reasons that Keiron states. Another good reason for branches is planned development that is out of sync with other planned development. That is, one or two developers have a major feature to work on, over a month or two, that is going to straddle a number of releases, and they simply will not have working code available during that time period, and what they are doing would actually affect functionality if it were to be in the main branch. But with this major exception I can't think of any other situations, apart from the release maintenance scenario, where a branch is really called for. Just my opinion. Arved --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
