@Experimental seems to be more common (spark, rxjava, jgroups, ). I would rename the gemfire-junit module to gemfire-common and put the annotation there.
Anthony > On Sep 11, 2015, at 9:26 AM, Dan Smith <[email protected]> wrote: > > +1 for having Nitin as release manager > > I also really like Kirks suggestion of marking some new APIs as > experimental. How about using an @Incubating annotation that shows up in > the javadocs? > > -Dan > > On Thu, Sep 10, 2015 at 10:14 PM, Nitin Lamba <[email protected]> wrote: > >> Great suggestions Anthony! >> >> For starters, can I get PM rights in Geode JIRA? I should then be able to >> make these changes fairly quickly. Also, it may make sense to create an >> Agile board to prioritize the issues we need to get done for the first >> release. There are a lot of little tasks that we should start capturing... >> >> Best, >> Nitin >> >> ________________________________________ >> From: Anthony Baker <[email protected]> >> Sent: Thursday, September 10, 2015 8:41 PM >> To: [email protected] >> Cc: [email protected] >> Subject: Re: Releasing Geode (was Re: September 2015 Report) >> >> 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 <[email protected]> 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 <[email protected]<mailto:[email protected] >>>> >>> Sent: Thursday, September 10, 2015 3:42 PM >>> Subject: Re: Releasing Geode (was Re: September 2015 Report) >>> To: <[email protected]<mailto:[email protected]>>, < >> [email protected]<mailto:[email protected]>> >>> >>> >>> On Thu, Sep 10, 2015 at 10:01 AM, Ashvin A <[email protected]<mailto: >> [email protected]>> 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. >>> >>> >> >>
