On Jan 24, 2008, at 5:42 PM, Kevan Miller wrote:
On Jan 24, 2008, at 8:23 PM, David Jencks wrote:
On Jan 24, 2008, at 1:49 AM, Rick McGuire wrote:
David Jencks wrote:
The specs tree seems to be in a mess with stuff in branches and
waay too much stuff in trunk, and many trunk poms having a xxx-
SNAPSHOT version where the latest tag is xxx.
I've attempted to document our previous decisions on spec
development and release in specs/branches/README:
WARNING
DO NOT DEVELOP ANY SPECS UNDER BRANCHES OR COPY ANY VERSIONS
INTO BRANCHES
ALL DEVELOPMENT MUST TAKE PLACE UNDER TRUNK
ANY CODE UNDER BRANCHES IS AN ERROR AND SHOULD BE CLEANED UP AS
SOON AS POSSIBLE
and specs/trunk/README.txt:
Structure
========
Only specs under active development should be in trunk. Once
you release, delete the trunk. If you need to make a change or
bugfix, copy the latest tag into trunk and work with that.
Be certain that all dependencies are marked "provided"
Do not copy any code into branches under any circumstances.
I'm not sure I agree with this. The documented procedures for
releasing involves moving the trunk version into branches using
the eventual final release name. Once moved, the poms are
updated to remove the -SNAPSHOT and the release candidates are
built. Any changes resulting from the voting process get made in
the branch, and only once the release vote has passed is the
branched moved into the tag.
I do like that aspect of the process, since it allows you to see
at a glance what stage you're in. The other principles I agree
with. All development should take place in trunk. No changes
should be made to any files once it is tags. Branches should be
reserved just for that transitional zone between termination of
active development and finalization of the release.
I guess I need to re-read the documentation for how to do a
release, but I think it's wrong. In particular I thought what we
voted on had to be built from a tag, not something in branches or
trunk. I thought if a release vote failed we deleted the tag.
That's not what I recall. There's documentation here -- http://
cwiki.apache.org/GMOxPMGT/release-branching-process.html There were
of course dev list postings. Suppose we can try to search back
through the list.
Like I said, the documentation is wrong, even if we voted on it and
haven't discussed since:-) I'm fairly certain that Dain did not
release specs through branches but directly from trunk using the
release plugin. Should I start a new thread?
basically:
-- for specs, gshell, xbean, components etc, releasing from trunk
directly using the release plugin is the only way to go
-- for geronimo, we should use the release plugin to create a branch,
stabilize, and release from a branch.
-- in the hopefully near future we will be releasing small enough
bits of geronimo so everything or almost everything can be released
directly without preliminary branching (yes, this might be an
unrealistic dream)
thanks
david jencks
For the specs at least, which we release individually, there is no
point in copying anything to branches. The release plugin can
create the tag directly from trunk just fine and much better than
I could by hand. When it constructs the release artifacts it
checks out from the tag it created.
The reason to copy to branches is to help prevent accidental/ill-
timed commits as a release was being prepared. Given the infrequent
nature of spec development, I don't view this as a big exposure.
So, I don't see the point in branches unless we are actually going
to branch or need to do manual cleanup before a release (such as
with all of geronimo at present.... an unfortunate situation)
thanks
david jencks
Rick
Building
========
The is normally no root pom, so you need to build specs
individually.
To build you will need:
* J2SE SDK 1.5+ (http://java.sun.com/j2se/1.4.2)
* Maven 2.0.7+ (http://maven.apache.org)
To build all changes incrementally:
mvn install
To perform clean builds, which are sometimes needed after some
changes to the
source tree:
mvn clean install
Releasing
=========
Use the maven-release-plugin.
Stage to your people.apache.org account or to your local machine
and scp to people.apache.org.
After a release vote has passed use the maven-stage-plugin to
transfer the voted artifacts to the apache release repo.
-----------------------------------
Please review, fix, and if you think this isn't what we agreed
on complain.
thanks
david jencks
