[Jboss-dev-forums] [Design of JBoss Build System] - Re: Requirements - Top level build - versioning

[<ad...@jb...>]

"rya...@jb..." wrote : 
  | 2.  A developer can call the "materialize" target to traverse all the component-infos and generate a materialized-versions.xml.  If there are conflicts, they will need to be resolved manually.  This file is not source controlled, it is a product of the build.
  | 

No, it is very important that this is versioned in cvs. It defines the release.
The "materialize" should be done as a part of the release process.

I haven't discussed the release use cases yet either, but...

e.g.
1) 4.0.3beta - developers happily continue developing, maybe there are conflicts
which they discover through warnings from the build or through testing problems

2) pre-4.0.3final - the release manager or qa, materialize the dependencies in their own
local workspace - this fixes the release versions and also helps to discover conflicts
At this point, a discussion can start on conflict resolution

3) 4.0.3 final - the release manager branches cvs (allowing other developers to continue to use the lax build scripts for the next release - goto 5) 
4) 4.0.3 final - the release manager commits the materialized build scripts and tags everything with the release id in cvs

5) 4.0.4 beta - see (1)

It is fairly obvious to me that steps 2 through 4 can be done with the help of build
targets. 

(3) and (4) can be pretty much automated, e.g.
cd jbossas
ant make-release -Dtag=4.0.3final -Dnext=4.0.4beta
which is only done when the release manager is happy that (2) is complete
It could even upload the final binaries to sourceforge.

Of course, knowing cvs, and the fact that this is a human process (people make
mistakes) it is never quite that simple :-)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878424#3878424

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3878424