Thanks Nitin, >> My preference would be for dot releases instead of alpha1, apha2, beta, RC, etc. Other thoughts? +1 on this...If we are planning to do only one intermediate release before 1.0 release (as mike was suggesting) we can call this 0.5.
I had looked into the task/tickets for alpha release; i was trying to see if we have any additional intermediate releases and requirement for them. -Anil. On Mon, Nov 30, 2015 at 3:28 PM, Nitin Lamba <ni...@ampool.io> wrote: > 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) > > > > > > >
