Bo,
> As we now get distribution setup working properly, I think this is a
> good time to discuss and agree a release mechanism according to Apache
> way. Per my observation from other Apache incubator projects such as
> ServiceMix and Tuscany, we can start with milestone releases (M1, M2,
> ...Mx), but I am not sure if we can do the major 2.0 release before
> graduation, or it has to wait after graduation. I also observed
> following typical release setup:
We CAN do an actual "2.0" release in the incubator if we want to. However,
it's generally "discouraged" due to branding issues, marketing issues,
etc.... As long as we're in the incubator, the branding, docs, etc... all
MUST make sure there is no confusion that it's an incubator projects. ALL
jars MUST have "incubator" in the name. (Example: the lib/cxf.jar in the
distribution is currently "wrong" and wouldn't pass the PMC. Yoko got hit by
that.) Etc... Also, you cannot really "market" a release done in the
incubator. We cannot really do press releases and such.
Cause of that, after you graduate and do a release, certain things would
change. (Like the classpaths would have to change from cxf-incubator.jar to
just cxf.jar, etc...)
That said, there is a discussion going on now about what a incubator project
MUST do. The Felix community tried to graduate without ever doing even a
milestone release or preparing a release candidate or anything. That's
didn't go over well and they've since withdrawn the graduation vote until
they can produce a release candidate. Producing a release is not REQUIRED
in the incubator, but a project needs to show that it understands the steps
required to do a release. If we properly do a couple milestones, we should
definitely be OK.
> Pre Release:
> 1. create a wiki page and start capturing features/bug fixes for the
> release
> 2. We can start a discussion thread and then come to a concensus on
> the final list
> 3. All release items should be tracked by JIRA
> 4. We can start a parallel thread on the release date
Actually, discussing a "release date" is also usually discouraged, but not
always. The normal procedure is to track the features/bugs that need to be
fixed/implemented for the milestone/release, and when it gets real close to
being done, then start building release candidates, etc... It doesn't get
released until the issues are complete, etc...
It's generally a bit different (more like opposite) than the corporate way of
pick a date and start scrapping bugs/features/etc... until you can meet the
date. When the agreed upon features/etc... are done, then you work on
releasing it. Basically, if the community thought those features/fixes were
important for the release, getting them in is more important than meeting
some artificial, date imposed limitation.
> Release process:
> 1. We should do a code freeze and put out a release candidate (RC1)
> 2. Allow minimum of one week for people to test/verify the RC
> 3. If there are major issues maybe do a RC2 and follow the issue process.
> 4. If a majority is happy then we can do a code freeze and cut out a
> release.
> The important thing is that everything is decided based on a public
> voting on the list. (only binding votes are counted). For incubator
> projects, I guess PPMC has to vote on a release. Are these the correct
> understanding of release process? Do mentors have any advice on this?
In general, in the incubator, step 4 usually expands out to:
for (int x = 0; x < 4; x++) {
4) Cut a "release", place on a public ftp/http site, start the PPMC vote.
5) After 72 hours, if PPMC vote passes and no issues come up from that
vote, propose the release vote for the incubator PMC.
6) Take feedback from PMC, fix all the issues.
}
7) After 72 hours of PMC votes and no more issues discovered, then actually
release.
That said, I've never heard of a projects first attempt at a release go
through the incubator PMC on the first try. It usually takes a couple weeks
(at least) to get the first one out the door. I think Tuscany took about
3-4 weeks. Yoko is going on 7 weeks. etc... We SHOULD be in better shape
since a couple of us have gone through it with Yoko/Tuscany/Others so we may
be able to resolve more issues before hand.
For those at IONA, it might be a good idea to sit down with the Yoko folks
over lunch or coffee or something and just chat with them about what they've
gone through and learned. Feel free to pick their brains. Then come
back here and post a summary so we can all learn.
> The important thing is that everything is decided based on a public
> voting on the list. (only binding votes are counted). For incubator
> projects, I guess PPMC has to vote on a release. Are these the correct
> understanding of release process? Do mentors have any advice on this?
For incubator projects, there are two votes, PPMC and PMC. The PMC vote is
not a normal Apache release vote in that -1 votes are basically a veto until
the issue is corrected. It's much closer to a code change vote in that
regards.
Enjoy!
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
[EMAIL PROTECTED]
