incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Coho Release tool *MENTOR INPUT NEEDED*
Date Sat, 24 Mar 2012 00:52:57 GMT
Hi,

On Thu, Mar 22, 2012 at 11:26 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> On Thu, Mar 22, 2012 at 7:59 PM, Tim Kim <timkim85@gmail.com> wrote:
>> The coho tool has been updated and I'm hoping we're ASF release compliant
>> now. This is now what coho produces: http://people.apache.org/~goya/
>
> Cool, thanks. I'll give it a closer look tomorrow.

We're getting closer. Some comments though:

* The NOTICE, license, readme.md and version files at the top of the
release tree should ideally go inside the src archive. That's the
official release artifact, so it should contain all relevant details.
* Why are some of the files in the root directory in lower case and
others in upper?
* The readme.md file is outdated. More generally also many of the
component READMEs still refer to PhoneGap.
* The source archive should contain the incubator disclaimer [1]. The
typical approach is to put it into a DISCLAIMER file.
* The source archive contains the .git directories of the cloned
components. Besides the extra weight in the release package, this is
troublesome as it implies that we're releasing the entire version
history of the project instead of just the current state.
* SHA1 checksums would be nice in addition to the MD5 ones.
* Related to the first point, the src archive has no top-level
documentation or build instructions.

I'll try to do a second pass tomorrow with licensing and source headers in mind.

PS. As a general comment, I've seen many projects use this idea of a
custom release script constructing release packages using an elaborate
sequence of steps. In practice they all end up having trouble when the
script starts to get outdated and nobody notices that until it's time
to cut a release (or perhaps not even then). An IMHO better approach
is to treat the exact contents of a normal source checkout as the
release source. For Cordova this could mean simply using "git archive"
to package up the tagged source trees, signing those tarballs, and
using the resulting files as the official source release.

[1] http://incubator.apache.org/guides/branding.html#disclaimers
[2] http://www.apache.org/dev/release-signing.html#basic-facts

BR,

Jukka Zitting

Mime
View raw message