You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Nitin Lamba <ni...@ampool.io> on 2015/12/01 00:28:17 UTC

Re: Review of 1.0.0-alpha1 issues

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 <ag...@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 <ab...@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_XsA@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 <ab...@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 <wm...@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 <ab...@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
> <de...@geode.incubator.apache.org>*
>
>
>
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>
>
>

Re: Review of 1.0.0-alpha1 issues

Posted by Michael Stolz <ms...@pivotal.io>.
I would like to see one alpha. I don't think we're sure how solid some of
this stuff is.

"Testing cannot prove the absence of bugs...only the presence."

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771
On Nov 30, 2015 4: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 <ag...@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 <ab...@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_XsA@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 <ab...@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 <wm...@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 <ab...@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
> > <de...@geode.incubator.apache.org>*
> >
> >
> >
> >
> >
> > --
> > -John
> > 503-504-8657
> > john.blum10101 (skype)
> >
> >
> >
>

Re: Review of 1.0.0-alpha1 issues

Posted by Mark Bretl <mb...@pivotal.io>.
@Anthony - I think your git flow statement was meant to be 'git flow
feature track GEODE-608' for helping with RAT integration. I will take a
look at the branch.

As for the release numbering/naming discussion...I agree with 1.0.0-alpha1
for the upcoming release.

--Mark

On Tue, Dec 1, 2015 at 11:46 AM, Anthony Baker <me...@yahoo.com.invalid>
wrote:

> I just resolved GEODE-611.
>
> I did some initial work on GEODE-608 and it’s available on a feature
> branch [1].  Next step is to whittle down the excludes list and fix the
> failures in conjunction with GEODE-18.  If someone wants to jump in on this
> work that would be great.
>
> Thanks to Niall and Nitin for helping drive this forward!
>
> Anthony
>
>
> [1] `git flow feature track GEODE-611`
>
> > On Dec 1, 2015, at 11:39 AM, Nitin Lamba <ni...@ampool.io> wrote:
> >
> >  GEODE-608/609/611: I see activity on these JIRAs but aren't assigned to
> anyone. Also, can these be marked 'in Progress'?
>
>


-- 
Mark Bretl
Software Build Engineer
Pivotal
503-533-3869
www.pivotal.io

Re: Review of 1.0.0-alpha1 issues

Posted by Anthony Baker <me...@yahoo.com.INVALID>.
I just resolved GEODE-611.

I did some initial work on GEODE-608 and it’s available on a feature branch [1].  Next step is to whittle down the excludes list and fix the failures in conjunction with GEODE-18.  If someone wants to jump in on this work that would be great.

Thanks to Niall and Nitin for helping drive this forward!

Anthony


[1] `git flow feature track GEODE-611`

> On Dec 1, 2015, at 11:39 AM, Nitin Lamba <ni...@ampool.io> wrote:
> 
>  GEODE-608/609/611: I see activity on these JIRAs but aren't assigned to anyone. Also, can these be marked 'in Progress'?

Re: Review of 1.0.0-alpha1 issues

Posted by Nitin Lamba <ni...@ampool.io>.
Great discussion!

So we're certainly cutting an initial (alpha1) release. Depending on its completeness/ quality, we can decide another alpha/ beta/ RC/ etc.

@Anil: though I also prefer dot releases, Geode is somewhat different in that it is a mature codebase out of the gate. So maybe it should be '0.9-alpha1' :)

Let's focus on '1.0.0-alpha1' for now, and we can pick-up any residual ideas/ views during the ClubHouse later this month. I've created the version within JIRA (can be renamed easily). 

Per Anthony's first e-mail, following is the status/ questions:
- GEODE-32: If the process steps on the Wiki look fairly stable, I'll resolve this JIRA. Will wait until COB today to get any feedback/ questions
- GEODE-18: @Dick: any updates?
- GEODE-608/609/611: I see activity on these JIRAs but aren't assigned to anyone. Also, can these be marked 'in Progress'?

Thanks,
Nitin 

________________________________________
From: shaposhnik@gmail.com <sh...@gmail.com> on behalf of Roman Shaposhnik <ro...@shaposhnik.org>
Sent: Monday, November 30, 2015 9:40 PM
To: dev@geode.incubator.apache.org
Cc: Anthony Baker
Subject: Re: Review of 1.0.0-alpha1 issues

On Mon, Nov 30, 2015 at 5:39 PM, Anilkumar Gingade <ag...@pivotal.io> wrote:
> 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.

On the other hand, alpha/beta release labels clearly send signal to your
user community to start testing and providing feedback. Alphas says:
do it now or later, beta says: do it now or forever hold your peace.

This worked well for Hadoop 2.0 release.

Thanks,
Roman.

Re: Review of 1.0.0-alpha1 issues

Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Nov 30, 2015 at 5:39 PM, Anilkumar Gingade <ag...@pivotal.io> wrote:
> 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.

On the other hand, alpha/beta release labels clearly send signal to your
user community to start testing and providing feedback. Alphas says:
do it now or later, beta says: do it now or forever hold your peace.

This worked well for Hadoop 2.0 release.

Thanks,
Roman.

Re: Review of 1.0.0-alpha1 issues

Posted by Anilkumar Gingade <ag...@pivotal.io>.
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 <ag...@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 <ab...@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_XsA@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 <ab...@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 <wm...@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 <ab...@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
> > <de...@geode.incubator.apache.org>*
> >
> >
> >
> >
> >
> > --
> > -John
> > 503-504-8657
> > john.blum10101 (skype)
> >
> >
> >
>