clean(goal)
Example of process, using fictious product.
Project Name:KungFoo
Version in TRUNK:1.5-SNAPSHOT
Desired Release Version: 1.5
release:prepare
1) Create a branch off of TRUNK for the release.
BRANCH/1.5 now exists.
2) Update pom versions in BRANCH/1.5 to reflect version "1.5"
3) Commit pom changes into SCM.
4) Update pom versions in TRUNK to be the new development version
"1.6-SNAPSHOT"
5) Commit pom changes into SCM.
Current State:
TRUNK : 1.6-SNAPSHOT
BRANCH/1.5 : 1.5
Binary : n/a
release:propose
1) Kick off full build.
Compiles and installs (into local repo) all of the artifacts.
Executes the reports.
Inject the SCM revision into a pom/properties for future reference.
Include the SCM revision # or buildnumber in the artifact name.
Creates...
KungFoo-1.5.jar
KungFoo-1.5-sources.jar
KungFoo-1.5-javadoc.jar
KungFoo-1.5-bin.tar.gz
KungFoo-1.5-bin.tar.bz2
KungFoo-1.5-bin.zip
2) PGP Sign all of the binaries.
Results...
KungFoo-1.5.jar.asc
KungFoo-1.5-sources.jar.asc
KungFoo-1.5-javadoc.jar.asc
KungFoo-1.5-bin.tar.gz.asc
KungFoo-1.5-bin.tar.bz2.asc
KungFoo-1.5-bin.zip.asc
3) Deploy all binaries, sha1, md5, asc files to staging repository.
For apache, this will be likely be in
https://people.apache.org/build-staging-repository/
(NOTE: This repository does not exist yet)
4) Announce to dev mailing-list the proposed release.
Current State:
TRUNK : 1.6-SNAPSHOT
BRANCH/1.5 : 1.5
Binary : In staging directory.
release:accept
1) Create TAG/1.5 off of BRANCH/1.5
2) Copy all binaries for KungFoo-1.5 from staging to release
repository (central).
3) Verify PGP signature of binaries in remote release repository.
4) Deploy the site.
release:clean
1) Remove KungFoo-1.5 binaries from the staging repository.
What (if any) effect do these targets have on produced websites? Or is that
still a completely separate process because different projects will want to
do different things?
Hope this helps start the flow of discussion...
- Joakim Erdfelt
Craig McClanahan
Daniel Kulp wrote:
> Jason and I have had some chats about this, but I thought it might be
good
> to bring this up to a wider audience...
>
>
> With more and more Apache projects (specifically incubator projects)
using
> maven, there are a lot more people that are running into "issues"
related
> to the apache requirements that are imposed on the build/release
> processes. IMO, Maven itself should act as the "ideal model" for how
to
> do those things. Thus, when a question comes up, we can point to maven
> and say "look how they are doing it." So the first question
is: does
> that make sense?
>
> The problem is, Maven doesn't seem to do things "correctly", or at least
> makes things hard(er) to do correctly.
>
> 1) The LICENSE/NOTICE files in the META-INF dir of the jar - currently,
> none of the maven plugins do this at all. I've seen projects handle
> this in a couple different ways. Some projects put them in the
> src/main/resources... dir like other resources, but that kind of hides
> them. Others put them in the same dir as the pom.xml and add a "."
> resource dir, but that breaks eclipse:eclipse. Both have the issue
> of having BUNCHES of copies of the LICENSE and NOTICE files to maintain,
> which sucks.
>
> There are a couple options.One option that I understand is coming in
> 2.1 is the ability to access stuff from the "parent" directory. Shared
> resources type things. Thus, a single copy could be used.
> Honestly, I'd like to see a "Apache-Maven" plugins (and a Incubator
> subclass plugin) that would automatically add those files automatically
> when possible.
>
> One note: according to http://www.apache.org/legal/src-headers.html, all
> Apache releases done AFTER November 1, 2006 must have the license/notice
> files done correctly. Thus, this item really needs to be taken care of
> REAL SOON NOW.
>
>
> 2) The release process - I honestly think Maven does this "wrong." At
> least for incubator projects, we need to do the
> tagging/build/signing/etc.. first, then vote on the resulting binaries.
> This definitely doesn't seem to be what maven is doing. They seem to
> vote on the "state of the code in the repository", then do the release
> steps.I think it would be good if the processes that were used could
> act as an example, especially for the incubator folks that are learning.
>
> My (somew
