Xavier Hanin wrote:
On 3/20/07, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
On Wed, 14 Mar 2007, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> I think it would be a good thing to produce a first incubating
> version of Ivy early April, and I would like to check what we need
> to do, and who does what.
We have a pretty detailed step by step guide at Ant[1] that show how
we do it over there. In general the exact process of doing a release
is different between ASF projects but there are a few things that are
common:
* the distribution must only contain stuff we are allowed to
distribute
I think this is ok. For external dependencies, I think they are all ok
since
either from Apache, or used by other Apache projects. We also have a
dependency on xooki for the documentation, which is released under ASL v2.
There is also one class largely inspired by a Maven class, but I think this
is not a problem. Xooki itself has some piece of codes inspired by
tiddlywiki (BSD) and dojo ( Academic Free
License<http://opensource.org/licenses/afl-2.1.php>
v2.1)
Is xooki distributed? or just depended on to create the distros?
* all LICENSE and NOTICE files are in place (this also means inside
the JAR file in the case of binary distributions), all project files
contain the license headers
I think I see what to do for LICENSE and NOTICE, but I'm not sure for
license headers. All java source files have the proper license header. But
should all xml files, including files used for unit tests and examples,
include the header? What about properties files? HTML files from the
documentation?
* the distribution files are signed with a valid PGP key.
Sidenote: make sure to catch Steve and myself (don't know whether
any other Ant people will be around) as well as any other Apache
people you will meet in Amsterdam and make sure we sign the key you
intend to use for the final release. There probably will be a
keysigning event at ApacheCon.
Does it mean this step is necessary before I can release a first alpha or
beta version? Because I would like to try to release it before ApacheCon.
As Jan said, we can do that together. if you look at the full apache
release rules (where are they, BTW?), the PMC members are meant to
verify that that the built artifacts are what they say they are, which
may include rebuilding the files and comparing checksums on the
individual .class files in the JAR. This is there to catch malicious
build managers putting in back doors.
So >1 person should be building the file anyway...any of the people who
are in the apache trustweb can sign the release.
* before the distribution files can be copied to the distribution area
you need at least 3 +1s from PMC members and more +1s than -1s.
* people will vote on the distribution files, so prepare what you want
to release before calling for a vote.
Ok, so I'll first commit the required files (NOTICE, LICENSE, DISCLAIMER,
and a release guide) to see if things seems ok, then I'll prepare a release
and put it in my user space on the apache web site to ease evaluation and
start the vote, first on this list, then if it's ok on the
[EMAIL PROTECTED] Is
it a correct way to proceed?
I should subscribe to [EMAIL PROTECTED], shouldn't I?
So I would like to know what do we need to do to make such a
> release. What is the process of releasing software in the incubator?
It is not too different from the "normal" way of making a release
AFAIU[2]. Your mentors are supposed to be Incubator PMC members, so our
+1s should be enough to ensure the quorum.
> Who can perform the remaining tasks?
In theory anybody can be the release manager, being a committer
certainly simplifies things 8-)
Ok, I'll take this task, unless somebody else want to take it.
Well volunteered :)
I may be able to add the ivy build to the bamboo build of smartfrog
we're setting up here, though its probably better as a public CI server.
Hmm. Maybe I could set it up at home, too.
What is needed at the end of the day is
-the JAR file
-the docs for offline use, maybe some examples.
-a source distribution that people can use to build the JAR file. If
it doesnt work, you don't get contributions back.
-the right headers on all the source files. Checkstyle can audit the
code for this.
-a release announcement PGP-signed by someone other apache people trust.
Other than that, the release guidelines are just that, guidelines.
For ant, we set up a wiki page of what has to be done...here is the
ant1.7 one:
http://wiki.apache.org/ant/Ant17/Planning
That's probably the first step...create a (draft) plan.
For the rest, well, I like to view the alpha release as a way of testing
the release process. You can do tricks like unzip/untar the redist
artifacts, then do a build of that project (pointing it away from the
normal ivy cache dirs), to check that your source redist is cleanly
buildable, and run checkstyle against the source to look for licensing
problems.
-steve
