I notice that there is a thread on gene...@incubator.apache.org "Help
reviewing PhotArk podling release", which is quite educational for what
we should expect
for a release.
I'd assert that our release should consist of the following items:
API
kato.api - The API interfaces and the services framework
The JSR-326 specification.
TCK - harness and tests.
Implementations
kato.cjvmti - The JSR-326 API JVMTI implementation
kato.native.cjvmti - The JVMTI agent.
kato.hprof - The implementation of JSR-326 API for hprof.
Tech demos:
kato.jdi - The JDI connector
kato.tools.katoview - The command line tool.
Eclipse tech demos:
kato.explorer - The API explorer for Eclipse
kato.hexeditor - the hexeditor
kato.rtexplorer - the java runtime explorer.
JDI connector eclipse plugin.
There are other packages, but these are dependencies for above and not
useful in their own right.
Perhaps our release would consist of all of these items, with each
category being a separate distributable. We'll
need to decide on their names at some point. I suggest the prefix we use
is "apache-kato-incubating-*".
To achieve this we will have to:
o Assess the state of what we have and fix it up where necessary.
o Create LICENSE and NOTICE files, where necessary.
o Get the jobs building on Apache's Hudson server (except for where
that is not possible, e.g. Windows builds).
o Write documentation for it all. Shouldn't be too onerous.
o Create a job on Hudson that will package all of the other builds, in
the process:
o generating checksums
o Incorporate licenses and notices
o generate source and binary distributables.
o Sign distributables
o Make available as a candidate release (under a home directory on
people.apache.org?)
o Call a vote on kato-dev mailing list.
o Formally ask the Incubator PMC permission to do a release
o Repeat and revise previous steps until acceptable.
o Put distributions in appropriate place
(|www.apache.org/dist/incubator/kato)
|o Modify website to include "downloads" page with links to current release.
o Announce the release to the world.
We'll need a release manager - I would like to do that if nobody has any
objections (+1's will be graciously accepted).
I should be able to get a key signed by some Apache folks in IBM Hursley
for signing the distributions.
(i.e. for the web of trust, and to establish that I'm not actually
BlueGene/Stoo )
At some point I'd like to have our release process documented on the
wiki/website.
I'd vote for a "milestone" release, that adequately descibes what we're
trying to achieve.
There are lots of other details to resolve, but how does all of that look?
Regards,
Stuart
Robert Burrell Donkin wrote:
On Tue, Sep 15, 2009 at 4:59 PM, Stuart Monteith <stuk...@stoo.me.uk> wrote:
<snip>
>-8 Snip
IIRC apache harmony uses milestones. might be worth taking a look at
how they do it...
- robert
--
Stuart Monteith
http://blog.stoo.me.uk/
