Thanks Anil, >From the best practices section:
"TODO: (move to a note) Notes on 0.x releases verses alpha and betas. It is better to use 0.x releases than to create numerous alphas and betas for 1.0. Conventionally, 0.x releases are aimed at early adopters only without a strong promise of easy upgrade or backwards compatibility. 0.x is a good designation for a product that is not feature complete but whose code is solid for those features which are implemented. " My preference would be for dot releases instead of alpha1, apha2, beta, RC, etc. Other thoughts? As for the release tasks, perhaps you missed the Wiki page: https://cwiki.apache.org/confluence/display/GEODE/1.0.0-alpha1+%28First%29+Release The JIRA (Agile) Board is here: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=92&view=planning Was hoping to get more discussion/ feedback from the community on the Wiki before JIRA versions and tasks are created. Please review/ comment the contents, if not done already. Thanks, -Nitin ________________________________________ From: Anilkumar Gingade <aging...@pivotal.io> Sent: Monday, November 30, 2015 2:47 PM To: dev@geode.incubator.apache.org Subject: Re: Review of 1.0.0-alpha1 issues Here is more detail on versioning.... http://incubator.apache.org/guides/releasemanagement.html#best-practice-naming (under versioning section) Can we set a release task list... E.g.: What tasks/items are expected to complete to do an alpha, beta and final 1.0 release... -Anil. On Mon, Nov 30, 2015 at 1:33 PM, Anthony Baker <aba...@pivotal.io> wrote: > > On Nov 30, 2015, at 11:23 AM, Nitin Lamba <ni...@ampool.io> 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 > > http://zookeeper.apache.org/doc/r3.5.1-alpha/ > > > 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 <jb...@pivotal.io> > Sent: Monday, November 30, 2015 11:07 AM > To: dev@geode.incubator.apache.org > 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 <aba...@pivotal.io> 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 <wmark...@pivotal.io> > > wrote: > > > Huge +1 for GEODE-27 before release. > > On Mon, Nov 30, 2015 at 9:13 AM, John Blum <jb...@pivotal.io> 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 <aba...@pivotal.io> > > 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 > *dev@geode.incubator.apache.org > <dev@geode.incubator.apache.org>* > > > > > > -- > -John > 503-504-8657 > john.blum10101 (skype) > > >
