Thanks for jumping in Nitin! I suggest we: 1) Rename the JIRA version from 1.0.0-incubating to 1.0.0-incubating-alpha1. 2) Update the versionNumber property in gradle.properties accordingly (note: this may have downstream effects on other projects like SpringDataGemFire). 3) Agree on the remaining issues to be included in the alpha1 release (GEODE-77/18).
GEODE-77 seems to be progressing nicely. GEODE-18 (license headers) has been stalled out for awhile after some great initial work by Niall. Current release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12332343 <https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420&version=12332343> We should probably go through the API additions that are still in-progress and identify/annotate experimental features. Thoughts? Anthony > On Sep 10, 2015, at 7:13 PM, Nitin Lamba <ni...@ampool.io> wrote: > > > Thanks Roman and Greg for the opportunity/ challenge! Happy to help with the > initial release if the group agrees to it, and with your guidance/ support, > of course. > When do we start!? > Best, > Nitin > _____________________________ > From: Roman Shaposhnik <ro...@shaposhnik.org<mailto:ro...@shaposhnik.org>> > Sent: Thursday, September 10, 2015 3:42 PM > Subject: Re: Releasing Geode (was Re: September 2015 Report) > To: <aas...@gmail.com<mailto:aas...@gmail.com>>, > <dev@geode.incubator.apache.org<mailto:dev@geode.incubator.apache.org>> > > > On Thu, Sep 10, 2015 at 10:01 AM, Ashvin A > <aas....@gmail.com<mailto:aas....@gmail.com>> wrote: >> http://www.apache.org/dev/release-publishing.html#release_manager >> >> *"The common practice at Apache is for a single individual to take >> responsibility for the mechanics of a release. That individual is called >> the 'release manager.' Release managers take care of shepherding a release >> from an initial community consensus to make it to final >> distribution.Release managers do the work of pushing out releases. However, >> release managers are not ultimately responsible. The PMC in general, and >> the PMC chair in particular (as an officer of the Foundation) is >> responsible for compliance with requirements.Any committer may serve as the >> manager of a release.A release starts when the project community agrees to >> make a release. However, no release manager can make a valid release unless >> the community has taken the necessary steps to prepare in advance. The >> source code and build process must comply with the legal and intellectual >> property requirements for a valid release, and the project must have the >> infrastructure in place to correctly sign the release artifacts."* >> >> >> Is it important to be a committer to be a release manager? > > Somewhat, but it is much more important for a TLP. But even there I was an RM > for a Hadoop release before I was a committer on the project. > > Literally the only thing you can't do as an RM if you are NOT a committer on > the > project is cherry-picking commits into a release branch. But you know what? > This > is a bad practice anyway. This is something that appropriate original commiter > should be doing instead (which makes RM a bit more of a cat herder, but that's > ok ;-)). > > Thanks, > Roman. > >
