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) > > >
