cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <daniel.k...@iona.com>
Subject Re: CeltiXfire release process
Date Mon, 18 Sep 2006 14:29:54 GMT
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
daniel.kulp@iona.com

Mime
View raw message