Benson, Yes that would be much appreciated.
Here is a rough gamplan of what I *think* will be needed to do the release: - Branch from develop against a ticket for the overall release process - Update the version of all the artifacts and dependencies to 0.0.1-RC1-incubating or something like that - Create the tar.gz of the clean source tree. Sign that and place both the signed file and the tar.gz into my people's dir (if i have one of those) - Notify folks that this is available so they can pull it and attempt to build from that and validate the signature - Once folks agree it is good to merge that to master - Create a tar.gz of that and a signed file. Call a vote within the team. If that is good call a vote within IPMC. - IF NO - fix whatever is wrong. - If all good then do a maven deploy of the binary artifacts, source bundles, and javadocs - Upload the tar.gz of source and the signed file to our dist dir. And upload convenience binary build tar.gz and zip with sigs to our dist folder. Then create links to these from our downloads page. - Update JIRA that the release is closed. - Wash/Rinse/Repeat <note this all is with the understanding that we've done all the necessary review of dependencies, licenses, properly documented them, have our ECCN/encryption stuff properly filed> Might be missing a detail or two but does that sound roughly on the right rack? I had though the maven release plugin would be useful but looks like we'll just be able to use the versions plugin to update them and can do the other simple steps manually. Thanks Joe On Thu, Jan 8, 2015 at 3:46 PM, Benson Margulies <[email protected]> wrote: > Typically people set the maven assembly plugin for this and include it in > the build. Would you like me to pitch this in? > > > On Thu, Jan 8, 2015 at 2:48 PM, Mike Drob <[email protected]> wrote: > > > On Wed, Jan 7, 2015 at 9:22 PM, Joe Witt <[email protected]> wrote: > > > > > Josh > > > > > > Awesome. > > > > > > Honestly I believe we're good on the LICENSE, NOTICE, DISCLAIMER, > README. > > > All dependencies have been reviewed and checked for ASLv2 > compatibility. > > > > > > Will submit the infra ticket now for the dist/ path for keys files and > > > such. > > > > > > My guess is that the release artifact should be a tarball of all > source. > > > Could we literally just package up a clean source tree? Anyone else > have > > > views on this? > > > > > > > git archive -o [nifi-0.0.1-incubating.tar.gz] [release-tag] is a > perfectly > > reasonable thing to do. > > > > > > > > Ideally with this release we'd do it all properly including maven > > > artifacts, sources/javadocs, and so on. The Maven build does already > > > operate now off a single command at the root to build everything > > > (build-order is gone) and inherits from the apache parent. > > > > > > Will need to incorporate RAT. > > > > > > Thanks for all that - definitely gives some stuff to work on and look > > into. > > > > > > Thanks > > > Joe > > > > > > On Wed, Jan 7, 2015 at 10:10 PM, Josh Elser <[email protected]> > > wrote: > > > > > > > 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 > > > >>>>>> > > > >>>>>> > > > >> > > > > > >
