> On Nov 30, 2015, at 11:23 AM, Nitin Lamba <[email protected]> wrote: > > +1 > > I do have a fundamental question about versioning (rather what versions can > be taken for voting/ approvals): > > Can an 'alpha' which has known issues (like GEODE-27 or GEODE-386 for apache > namespace, etc) be taken all the way through the PMC process for approvals? > Such a release will have to be posted to maven/ apache builds but does it > meet the quality requirements for an 'Apache Release’?
Good question. I was assuming we would need to address GEODE-386 before graduation but not for the first release. > > Also, in the guidelines, I've seen references to dot releases 0.x.y up to the > 1.0 release but not 'alpha1', 'alpha2', 'RC1', etc. Maybe I missed a page > somewhere. Is there a preference/ mandate here? > Here are a few examples: https://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201509.mbox/%3ccalwht94xigohjrtimmqyx3gfodr2m8pyyp2fsnybrq6dat_...@mail.gmail.com%3E <https://mail-archives.apache.org/mod_mbox/hadoop-yarn-dev/201509.mbox/%3ccalwht94xigohjrtimmqyx3gfodr2m8pyyp2fsnybrq6dat_...@mail.gmail.com%3E> http://zookeeper.apache.org/doc/r3.5.1-alpha/ <http://zookeeper.apache.org/doc/r3.5.1-alpha/> http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-common/releasenotes.html <http://hadoop.apache.org/docs/r2.4.1/hadoop-project-dist/hadoop-common/releasenotes.html> (search for alpha, beta, etc) > If our versioning approach can be vetted, I agree with Anthony's suggestion > to have frequent releases scrubbing these issues - at least a few at a time. > > Roman/ others: any guidance here? > > Thanks, > Nitin > > ________________________________________ > From: John Blum <[email protected]> > Sent: Monday, November 30, 2015 11:07 AM > To: [email protected] > Subject: Re: Review of 1.0.0-alpha1 issues > > From my perspective, the (nearly) final, "releasable" POM is not needed > until we hit RC1. By then, RCs should be relatively stable, having only > simple changes (e.g. bug fixes) until final GA. Dependency additions, > exclusions should be worked out before/by RC1. > > On Mon, Nov 30, 2015 at 10:55 AM, Anthony Baker <[email protected]> wrote: > >> Let’s get really specific when we talk about “release”. GEODE-27 clearly >> needs to be addressed prior to a 1.0.0 release. Currently we are >> discussing a 1.0.0-alpha1 release which will be followed soon after by >> *-alpha2, *-alpha3, etc. >> >> Do we need GEODE-27 in 1.0.0-alpha1 or can it be deferred to a subsequent >> alpha release? >> >> Anthony >> >> >>> On Nov 30, 2015, at 10:24 AM, William Markito <[email protected]> >> wrote: >>> >>> Huge +1 for GEODE-27 before release. >>> >>> On Mon, Nov 30, 2015 at 9:13 AM, John Blum <[email protected]> wrote: >>> >>>> Looking ahead, 1 issue, among others, that should warrant careful >> attention >>>> before the 1.0.0 RC, is GEODE-27 >>>> <https://issues.apache.org/jira/browse/GEODE-27> [0]. Getting the POM >>>> file >>>> correct is not only important for Geode, but for developers building >>>> applications using Geode. Changing a POM file after a release is always >>>> messy and not recommended since most artifact servers (e.g. >> Artifactory), >>>> and even local Maven repos, cache the POM file for a given version. The >>>> only time it is ever appropriate to change a POM file is during a >> release >>>> of a *new* version (and typically non-GA/maintenance versions; i.e. when >>>> going from RC -> GA, the POM should remain fixed until the next >> major.minor >>>> version, e.g. 1.0 -> 1.1). The unfortunate, but necessary, GemFire 8.1 >> POM >>>> file change caused issues for developers recently; those developers were >>>> consuming GemFire indirectly. >>>> >>>> Thanks, >>>> -John >>>> >>>> [0] - https://issues.apache.org/jira/browse/GEODE-27 >>>> >>>> >>>> On Sun, Nov 29, 2015 at 7:40 AM, Anthony Baker <[email protected]> >> wrote: >>>> >>>>> ICYMI, Nitin created a sprint dashboard for the 1.0.0-alpha1 release >> [1]. >>>>> I’ve added a few issues to it based on the licensing reviews Niall and >>>> Dick >>>>> are doing. Here’s the summary: >>>>> >>>>> *** GEODE-32 / wiki page to document release process [2] >>>>> >>>>> Looks pretty good good. There are a few inline question marks to fill >>>> out. >>>>> >>>>> *** GEODE-18 / source file headers >>>>> *** GEODE-608 / Integrate RAT into build >>>>> I’ve added build support for RAT on the feature/GEODE-608 branch. This >>>>> should make closing out GEODE-18 easier. The excludes file is based on >>>> the >>>>> one attached to GEODE-18. There are a few more files to evaluate and >> the >>>>> entire excludes list should be reviewed for correctness. >>>>> >>>>> *** GEODE-610 / Review LICENSE and NOTICE >>>>> >>>>> Niall exported the source and dependent licenses that need to be fed >> into >>>>> edits on the LICENSE and NOTICE files. >>>>> >>>>> *** GEODE-611 / Replace Findbugs annotations >>>>> >>>>> We can replace the LGPL-licensed findbugs annotation library with an >> ASL >>>>> clean implementation. >>>>> >>>>> >>>>> Anthony >>>>> >>>>> >>>>> [1] >>>>> >>>> >> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning >>>>> [2] >>>>> >>>> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=57311453 >>>>> >>>>> >>>> >>>> >>>> -- >>>> -John >>>> 503-504-8657 >>>> john.blum10101 (skype) >>>> >>> >>> >>> >>> -- >>> >>> William Markito Oliveira >>> -- For questions about Apache Geode, please write to >>> *[email protected] >>> <[email protected]>* >> >> > > > -- > -John > 503-504-8657 > john.blum10101 (skype)
signature.asc
Description: Message signed with OpenPGP using GPGMail
