Regardless of what you call it, writing down exactly what was done to
make a RC is extremely important early on (I know that I sure can't
remember what I did last week, much less last release). I'm not sure if
release guide is formally defined somewhere, but enough information that
any other committer can come by after "you get hit by a train" and make
a release is extremely important. Using the CMS and making a page on the
website for this is extremely easy to do, IMO.
Another concern for how to actually make a release is the type of
packaging that is released. I not talking about the source/binary
release here, literally "what is Apache NiFi 0.0.1-incubating"? Is it a
tarball? Are there jars in Maven? etc. A tarball is pretty easy to make,
and likely the closest to what the build-order.sh script already does
(with Maven's help). I'm not sure if maven-released artifacts are quite
as important at this point -- if it's not, punting on that will help.
If/when you get to that point, look into the apache parent pom[1]. It is
extremely well automated to use the existing infrastructure to do it all
for you.
Without looking at official documentation (which is me being lazy,
sorry), some other things that will need to be thought about:
Start with the releases page [2]
* You *must* include a source artifact. It cannot have binaries. No Java
class files, no jars. A user must be able to download the source
artifact and build it all themselves. Artifacts which include binaries
are for user-convenience only and can optionally be provided as well.
* LICENSE, NOTICE and README must all be included in the top level of
the artifact. The NOTICE is the most painful and must include any
required third-party notices. [3]
* You will need to audit your dependencies to make sure that they are
ASLv2 compatible [4]
* Releases must be cryptographically signed (PGP) [5]. Your public key
should be published to known sites (e.g. pgp.mit.edu) and must be listed
in NiFi's KEYS file [6] (which does not yet exist, probably needs an
infra ticket to create your dist/ directory?).
* Verify that every source file contain the proper ASL header. The
release-audit-tool[7] (`mvn apache-rat:check`) is a wonderful tool that
can (and should, IMO) be integrated into your build process to prevent
people from accidentally committing new files between releases that do
not have the correct header.
And suddenly, this is really long :). Short answer: decide what the
release should look like (just a tarball?), start vetting your source
code for license headers, and looking into NiFi's dependencies and their
licenses.
[1] http://maven.apache.org/pom/asf/
[2] http://www.apache.org/dev/release.html
[3] http://www.apache.org/legal/src-headers.html
[4] http://www.apache.org/legal/resolved.html#category-x
[5] http://www.apache.org/dev/release-signing.html
[6] http://www.apache.org/dist/incubator/nifi/KEYS
[7] http://creadur.apache.org/rat/
Tony Kurc wrote:
I read the guide Joe linked and a lot of the sticky parts are marked "TODO"
and it looks like a work in progress
"Podlings can short circuit this process by starting out with written
release documentation. It is strongly recommended that Podlings invest time
looking at the best practices recommended in this document. By selection
and modification, sections of this document can be used to quickly and
easily bootstrap a release guide. "
Is step one putting together a release guide?
On Wed, Jan 7, 2015 at 9:26 PM, Joe Witt<[email protected]> wrote:
Hello
Just wanted to stir this one up a bit. Looks like all tickets pegged as
0.0.1 are resolved (2 remain as of now but seem likely to be resolved
shortly based on their comments). So working through the release steps
available on apache.org and via the link Brock sent.
Anyone interested in this part of the process or who has advice to help us
avoid landmines we're happy to hear it.
Thanks
Joe
On Thu, Dec 18, 2014 at 1:31 PM, Joe Witt<[email protected]> wrote:
Thanks Brock this is very helpful.
On Thu, Dec 18, 2014 at 1:27 PM, Brock Noland<[email protected]>
wrote:
Hi,
This is a decent guide which can be copied:
http://mrunit.apache.org/pmc/how_to_release.html
Brock
On Thu, Dec 18, 2014 at 10:17 AM, Joe Witt<[email protected]> wrote:
Folks,
Looking at the tickets that remain which are presently tied to 0.0.1
we're
probably 1-2 weeks out from this initial release. Can you provide
some
pointers/references or pointers on how to get this ball rolling and
any
rocks we must move before going down this path?
http://incubator.apache.org/guides/releasemanagement.html
That link seems really helpful but has a lot of TODOs for areas which
need
more explanation.
Thanks
Joe
