You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Niall Pemberton <ni...@gmail.com> on 2016/05/01 18:24:13 UTC
Re: What will it take to release geode 1.0?
On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io> wrote:
> I'm not sure if the docs are a prerequisite for graduation. I don't think
> there are specific requirements about the level of documentation for
> graduation, just about community involvement - which docs could help
> encourage :)
>
I think this is a grey area with the user docs being on a vendor site.
Theres a requirement that "every podling site sources should be maintained
in the podling's site SVN or git directory"[1]. Clearly geode meets this to
the letter of the law and I've seen other projects websites point to
external resources that are useful. Since theres a plan to donate them at
some point, my guess is it wouldn't be an issue.
[1] http://incubator.apache.org/guides/sites.html
> In any case we don't need to graduate or even be graduation ready to
> release 1.0. The version number 1.0 has no special meaning to the ASF as
> far as I can tell. But I think having regular releases and having an
> official non-milestone release will help us grow the community.
>
A release without a milestone/alpha/beta qualifier is going to indicate
this community thinks its ready for serious use - so while you're right
from a ASF perspective, it will have a special meaning for the wider geode
community. And while keeping the existing package names makes the
transition easier for existing gemfire users, a package rename in a later
version will add pain to the new vast(hopefully!) user base for geode. So I
would say do it now rather than later.
However, if you're going to change the package name, then its also a good
time to remove any deprecated features and correct/change any API's that
you're not 100% happy with - which may be alot more work than just changing
the package name.
Niall
>
> This page has some information on what's required for graduation:
>
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
>
> -Dan
>
>
> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <db...@pivotal.io> wrote:
>
> > We plan at some point to donate the docs so they'll be incorporated into
> > the repo. Is this a prerequisite to graduating from incubation?
> >
> > On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <kl...@pivotal.io> wrote:
> >
> > > The package renaming would most likely break some backwards
> compatibility
> > > between 1.0 and 2.0. I'd prefer to see the packages get renamed before
> > 1.0
> > > so we can change the packages of Message classes, etc in the same
> release
> > > that introduces the new JGroups.
> > >
> > > The packages are currently a mess of com.gemstone.*, com.vmware.*,
> > > joptsimple.*, org.json.* (would we change all four or just the
> > > gemstone/vmware packages?).
> > >
> > > I'm probably biting off more than I should, but I'd be willing head up
> > the
> > > package renaming effort.
> > >
> > > I think maintaining backwards compatibility (rolling upgrades included)
> > for
> > > releases following Geode 1.0 is a definite requirement. I'd like to see
> > the
> > > other discussion thread about defining the Geode protocol(s) converge
> > with
> > > this thread. Officially defining the communication protocols (cluster,
> > > client/server, etc) would ideally happen in conjunction with 1.0 so
> that
> > > it's concrete and less ambiguous for 2.0 and later releases.
> > >
> > > -Kirk
> > >
> > >
> > > On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <ds...@pivotal.io> wrote:
> > >
> > > > We've been releasing milestones of 1.0, but at some point we actually
> > > have
> > > > to release a real geode 1.0 :)
> > > >
> > > > What is keeping us from releasing geode 1.0 at this point? Just the
> > > issues
> > > > currently marked with Fix Version M3? I think we should nail down the
> > > scope
> > > > of 1.0 and track our progress to the 1.0 release.
> > > >
> > > > From the apache process perspective, I don't think 1.0 is any
> different
> > > > from the milestone releases we've done so far. The only difference
> with
> > > 1.0
> > > > is what it means to the geode community.
> > > >
> > > > Gemfire maintained backwards compatibility with previous releases for
> > > > persistent files, client/server, WAN, and P2P messaging. I think once
> > we
> > > > release 1.0 we should provide that same guarantee that the next geode
> > > > release will be backwards compatible with 1.0.
> > > >
> > > > We do still have the package renaming (GEODE-37) on the horizon. My
> > > > suggestion is that in the interests of getting 1.0 out the door, at
> > this
> > > > point we should just release geode 1.0 with the old packages and
> rename
> > > > packages in geode 2.0.
> > > >
> > > > Thoughts?
> > > >
> > > > -Dan
> > > >
> > >
> >
>
Re: What will it take to release geode 1.0?
Posted by Nitin Lamba <ni...@gmail.com>.
Sorry for the delay. Seems one JIRA is already present so created a few
more, as follows:
(a) gfsh help (GEODE-985)
(b) JMX end-points (GEODE-1465)
(c) properties file (GEODE-1466)
(d) servlet names for Dev and Admin REST (GEODE-1467)
Please feel free to update these issues, as appropriate.
I could start with GEODE-985 unless someone is already working on it.
Thanks,
Nitin
On Wed, May 11, 2016 at 12:33 PM, Anthony Baker <ab...@pivotal.io> wrote:
> Thanks Nitin! AFAIK we need new JIRA’s for those issues.
>
> Anthony
>
> > On May 11, 2016, at 11:49 AM, Nitin Lamba <nl...@apache.org> wrote:
> >
> > Sorry missed this thread last week.
> >
> > +1 on package-renaming to be picked-up after 1.0 release.
> >
> > However, the community should try to fix any visible Gemfire references.
> > Following are a few I know of:
> > (a) Rename Gemfire to Geode on gfsh commands and help (global replace in
> > CliStrings class; cleaner way is to use 'format' text using
> > GemFireVersion.getProductName)
> >
> > (b) Rename Gemfire to Geode on JMX end-points (probably rework on JMX,
> > management REST, and Pulse)
> >
> > (c) Renaming gemfire.properties to geode.properties
> >
> > Does anyone know if there are existing JIRAs for these? If not, I'll
> create
> > new ones and happy to drive at least a few of these for M3.
> >
> > Thanks,
> > Nitin
> >
> >
> > On Tue, May 3, 2016 at 9:19 PM, William Markito <wm...@pivotal.io>
> wrote:
> >
> >> Great discussion...
> >>
> >> On Tue, May 3, 2016 at 6:45 PM, Brian Dunlap <bd...@gmail.com>
> wrote:
> >>
> >>> R1 without package renaming sounds good.
> >>>
> >>
> >> Cool.
> >>
> >>
> >>>
> >>> Along with the R1 release info, it would be uber-helpful to clarify
> >>> cheese-moving public (and internal) API munging that's cooking with R2.
> >>>
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328142#GeodeModularizationProposal(workinprogress)-Packagenamingscheme
> >>>
> >>>
> >> Some things in this proposal sort of happened with the new layout of the
> >> artifacts and sub-modules in Geode, transparent to end users
> >> through geode-dependencies.jar, but a lot would be a work in progress
> while
> >> we refactor the code base and may require multiple releases... IHMO.
> >>
> >>
> >>> For example:
> >>> Will 2.0 require existing Gemfire clients to bite the
> >> com.gemstone.gemfire
> >>> bullet? (no yucky package passthrough mappers?)
> >>>
> >>
> >> Now the package rename (and not the artifacts renaming like jar files)
> >> could indeed affect GemFire clients but we, at Pivotal, are working on a
> >> solution to mitigate (or even completely avoid) that impact.
> >>
> >>
> >>> Does 2.0 include refactored Native Client stuff too?
> >>>
> >>>
> >> That is a good question and I would say that it does make sense given
> that
> >> we would then have a faster release of 1.0.0 without Native Client. - In
> >> fact we've started the work /process already and given that the
> community
> >> does accept it we should consider including it on 2.0. But for now, we
> >> should probably wait until that process is concluded.
> >>
> >>
> >>>
> >>> Thanks,
> >>> Brian -
> >>>
> >>>
> >> Thanks for feedback!
> >>
> >>
> >>>
> >>> On Tue, May 3, 2016 at 7:07 PM, William Markito <wm...@pivotal.io>
> >>> wrote:
> >>>
> >>>> @Anthony, what if we did:
> >>>>
> >>>> # M3
> >>>> GEODE-1028 Broken website link
> >>>> GEODE-1133 SeparateClassloaderTestRunner
> >>>> GEODE-1260 Source distribution version info
> >>>>
> >>>> # 1.0.0
> >>>> GEODE-1191 HDFS references
> >>>> GEODE-612 Update Jackson version since current version is not on
> >> Maven
> >>>> central
> >>>>
> >>>> Reasoning here being that we'd be working on other JSON related items
> >> for
> >>>> 1.0 as well and to not add much to M3. If you strongly believe it all
> >>>> should be in M3, fine as well.. I'm just trying to get M3 out sooner.
> >>>>
> >>>> @Brian, the current thinking would be to tackle package renaming (and
> >> all
> >>>> the testing related to it) in the next major release for Geode, making
> >>> 1.0
> >>>> the release to finalize the migration to ASF - And we would take all
> >> the
> >>>> lessons learned and efforts to 2.0 which would then come much faster
> >>> given
> >>>> that we wouldn't have to deal with licensing/clean up, while we learn
> >> how
> >>>> to release and iterate on new features. 2.0 would also be focusing on
> >>>> graduation from incubation... What do you think ?
> >>>>
> >>>>
> >>>> On Tue, May 3, 2016 at 4:50 PM, <bd...@gmail.com> wrote:
> >>>>
> >>>>> Did Kirk's note about package renaming make the M3 scope? I think it
> >>>> would
> >>>>> be great to start Geode's 1.0 on a consistent naming standard.
> >>>>> :)
> >>>>>
> >>>>> Pro-Geode!!!
> >>>>> Brian -
> >>>>>
> >>>>> Sent from my iPhone
> >>>>>
> >>>>>> On May 3, 2016, at 6:09 PM, Anthony Baker <ab...@pivotal.io>
> >> wrote:
> >>>>>>
> >>>>>> William,
> >>>>>>
> >>>>>> What do you think about including these in M3?
> >>>>>>
> >>>>>> GEODE-612 Update Jackson version since current version is not on
> >>>>> Maven central
> >>>>>> GEODE-1028 Broken website link
> >>>>>> GEODE-1191 HDFS references
> >>>>>> GEODE-1133 SeparateClassloaderTestRunner
> >>>>>> GEODE-1260 Source distribution version info
> >>>>>>
> >>>>>> Anthony
> >>>>>>
> >>>>>>
> >>>>>>> On May 3, 2016, at 3:49 PM, William Markito <wm...@pivotal.io>
> >>>>> wrote:
> >>>>>>>
> >>>>>>> Guys, restarting this thread to get a discussion going about M3,
> >>> 1.0.0
> >>>>> and
> >>>>>>> next - As the release manager for M3 here is what I'd like to
> >>>> propose.
> >>>>>>>
> >>>>>>> Any feedback is welcome and let's also reuse this thread to talk a
> >>>>> little
> >>>>>>> bit about roadmap as well ?
> >>>>>>>
> >>>>>>> # Current M3 Scope (
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
> >>>>>>> )
> >>>>>>>
> >>>>>>> GEODE-33
> >>>>>>> GEODE-823
> >>>>>>> GEODE-835
> >>>>>>> GEODE-919
> >>>>>>> GEODE-1146
> >>>>>>> GEODE-1168
> >>>>>>> GEODE-1203
> >>>>>>> GEODE-1259
> >>>>>>> GEODE-1278
> >>>>>>> GEODE-1293
> >>>>>>> GEODE-1316
> >>>>>>> GEODE-1256
> >>>>>>> GEODE-1267
> >>>>>>>
> >>>>>>> == Proposed scope & roadmap ==
> >>>>>>>
> >>>>>>> I'd like to breakdown the release a little bit and already start
> >>>>> planning
> >>>>>>> the next releases.
> >>>>>>>
> >>>>>>> # Geode 1.0.0-incubating M3
> >>>>>>>
> >>>>>>> GEODE-1316 Update @since tags to include GemFire or Geode in the
> >>>> version
> >>>>>>> name
> >>>>>>> GEODE-1293 Align code and docs for modules
> >>>>>>> GEODE-1278 AbstractPeerTXRegionStub should throw
> >>>>>>> TransactionDataNodeHasDeparted when remote cache is closed
> >>>>>>> GEODE-1267 NOTICE file improvements
> >>>>>>> GEODE-1256 Geode website - Unapproved licenses
> >>>>>>> GEODE-1203 gfsh connect --use-http reports a
> >> ClassNotFoundException
> >>>>>>> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5,
> >>>> asc.sha1)
> >>>>>>> GEODE-835 Replace joptsimple source with a binary dependency
> >>>>>>> GEODE-823 RC Feedback: Fix build artifacts
> >>>>>>> GEODE-33-1 Create project examples
> >>>>>>>
> >>>>>>> # Geode 1.0.0-incubating
> >>>>>>>
> >>>>>>> GEODE-33-2 Create project examples
> >>>>>>> GEODE-1331 gfsh.bat on Windows is incorrect
> >>>>>>> GEODE-1168 geode-dependencies manifest is missing jars that are
> >>>> present
> >>>>> in
> >>>>>>> the lib directory
> >>>>>>> GEODE-629 Replace use of org.json with Jackson JSON library
> >>>>>>> GEODE-607 the offheap package needs better unit test coverage
> >>>>>>> GEODE-136 Fix possible NullPointerException in Gfsh's 'list
> >> regions'
> >>>>>>> command's GetRegionsFunction.
> >>>>>>>
> >>>>>>> # Geode 1.X.0-incubating
> >>>>>>>
> >>>>>>> GEODE-17 Provide Integrated Security
> >>>>>>> GEODE-11 Lucene Integration
> >>>>>>> GEODE-33-3 Create project examples
> >>>>>>>
> >>>>>>> # Geode 2.0.0-incubating
> >>>>>>>
> >>>>>>> GEODE-72 Remove deprecated APIs from Geode
> >>>>>>> GEODE-37 Package renaming
> >>>>>>> ---------------------------
> >>>>>>>
> >>>>>>> Comments:
> >>>>>>>
> >>>>>>> GEODE-33 would be broken into 3 different tasks, where on M3 we
> >>> would
> >>>>> start
> >>>>>>> with the example structure and a few examples, and incrementally
> >> add
> >>>>> more
> >>>>>>> examples in the next releases.
> >>>>>>>
> >>>>>>> GEODE-37 is the package rename which due to the huge effort in
> >>> testing
> >>>>> and
> >>>>>>> with the goal to complete the removal of deprecated API's
> >> (GEODE-72
> >>>> and
> >>>>>>> it's sub-tasks) would be pushed to 2.0. This would also allow
> >> faster
> >>>>>>> releases in 1.0.0 series.
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <
> >>>>> niall.pemberton@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I'm not sure if the docs are a prerequisite for graduation. I
> >>> don't
> >>>>> think
> >>>>>>>>> there are specific requirements about the level of documentation
> >>> for
> >>>>>>>>> graduation, just about community involvement - which docs could
> >>> help
> >>>>>>>>> encourage :)
> >>>>>>>>
> >>>>>>>> I think this is a grey area with the user docs being on a vendor
> >>>> site.
> >>>>>>>> Theres a requirement that "every podling site sources should be
> >>>>> maintained
> >>>>>>>> in the podling's site SVN or git directory"[1]. Clearly geode
> >> meets
> >>>>> this to
> >>>>>>>> the letter of the law and I've seen other projects websites point
> >>> to
> >>>>>>>> external resources that are useful. Since theres a plan to donate
> >>>> them
> >>>>> at
> >>>>>>>> some point, my guess is it wouldn't be an issue.
> >>>>>>>>
> >>>>>>>> [1] http://incubator.apache.org/guides/sites.html
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> In any case we don't need to graduate or even be graduation
> >> ready
> >>> to
> >>>>>>>>> release 1.0. The version number 1.0 has no special meaning to
> >> the
> >>>> ASF
> >>>>> as
> >>>>>>>>> far as I can tell. But I think having regular releases and
> >> having
> >>> an
> >>>>>>>>> official non-milestone release will help us grow the community.
> >>>>>>>>
> >>>>>>>> A release without a milestone/alpha/beta qualifier is going to
> >>>> indicate
> >>>>>>>> this community thinks its ready for serious use - so while you're
> >>>> right
> >>>>>>>> from a ASF perspective, it will have a special meaning for the
> >>> wider
> >>>>> geode
> >>>>>>>> community. And while keeping the existing package names makes the
> >>>>>>>> transition easier for existing gemfire users, a package rename
> >> in a
> >>>>> later
> >>>>>>>> version will add pain to the new vast(hopefully!) user base for
> >>>> geode.
> >>>>> So I
> >>>>>>>> would say do it now rather than later.
> >>>>>>>>
> >>>>>>>> However, if you're going to change the package name, then its
> >> also
> >>> a
> >>>>> good
> >>>>>>>> time to remove any deprecated features and correct/change any
> >> API's
> >>>>> that
> >>>>>>>> you're not 100% happy with - which may be alot more work than
> >> just
> >>>>> changing
> >>>>>>>> the package name.
> >>>>>>>>
> >>>>>>>> Niall
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> This page has some information on what's required for
> >> graduation:
> >>>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
> >>>>>>>>>
> >>>>>>>>> -Dan
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <
> >> dbarnes@pivotal.io
> >>>>
> >>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> We plan at some point to donate the docs so they'll be
> >>> incorporated
> >>>>>>>> into
> >>>>>>>>>> the repo. Is this a prerequisite to graduating from incubation?
> >>>>>>>>>>
> >>>>>>>>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <klund@pivotal.io
> >>>
> >>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> The package renaming would most likely break some backwards
> >>>>>>>>> compatibility
> >>>>>>>>>>> between 1.0 and 2.0. I'd prefer to see the packages get
> >> renamed
> >>>>>>>> before
> >>>>>>>>>> 1.0
> >>>>>>>>>>> so we can change the packages of Message classes, etc in the
> >>> same
> >>>>>>>>> release
> >>>>>>>>>>> that introduces the new JGroups.
> >>>>>>>>>>>
> >>>>>>>>>>> The packages are currently a mess of com.gemstone.*,
> >>> com.vmware.*,
> >>>>>>>>>>> joptsimple.*, org.json.* (would we change all four or just the
> >>>>>>>>>>> gemstone/vmware packages?).
> >>>>>>>>>>>
> >>>>>>>>>>> I'm probably biting off more than I should, but I'd be willing
> >>>> head
> >>>>>>>> up
> >>>>>>>>>> the
> >>>>>>>>>>> package renaming effort.
> >>>>>>>>>>>
> >>>>>>>>>>> I think maintaining backwards compatibility (rolling upgrades
> >>>>>>>> included)
> >>>>>>>>>> for
> >>>>>>>>>>> releases following Geode 1.0 is a definite requirement. I'd
> >> like
> >>>> to
> >>>>>>>> see
> >>>>>>>>>> the
> >>>>>>>>>>> other discussion thread about defining the Geode protocol(s)
> >>>>> converge
> >>>>>>>>>> with
> >>>>>>>>>>> this thread. Officially defining the communication protocols
> >>>>>>>> (cluster,
> >>>>>>>>>>> client/server, etc) would ideally happen in conjunction with
> >> 1.0
> >>>> so
> >>>>>>>>> that
> >>>>>>>>>>> it's concrete and less ambiguous for 2.0 and later releases.
> >>>>>>>>>>>
> >>>>>>>>>>> -Kirk
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <
> >> dsmith@pivotal.io>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> We've been releasing milestones of 1.0, but at some point we
> >>>>>>>> actually
> >>>>>>>>>>> have
> >>>>>>>>>>>> to release a real geode 1.0 :)
> >>>>>>>>>>>>
> >>>>>>>>>>>> What is keeping us from releasing geode 1.0 at this point?
> >> Just
> >>>> the
> >>>>>>>>>>> issues
> >>>>>>>>>>>> currently marked with Fix Version M3? I think we should nail
> >>> down
> >>>>>>>> the
> >>>>>>>>>>> scope
> >>>>>>>>>>>> of 1.0 and track our progress to the 1.0 release.
> >>>>>>>>>>>>
> >>>>>>>>>>>> From the apache process perspective, I don't think 1.0 is any
> >>>>>>>>> different
> >>>>>>>>>>>> from the milestone releases we've done so far. The only
> >>>> difference
> >>>>>>>>> with
> >>>>>>>>>>> 1.0
> >>>>>>>>>>>> is what it means to the geode community.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Gemfire maintained backwards compatibility with previous
> >>> releases
> >>>>>>>> for
> >>>>>>>>>>>> persistent files, client/server, WAN, and P2P messaging. I
> >>> think
> >>>>>>>> once
> >>>>>>>>>> we
> >>>>>>>>>>>> release 1.0 we should provide that same guarantee that the
> >> next
> >>>>>>>> geode
> >>>>>>>>>>>> release will be backwards compatible with 1.0.
> >>>>>>>>>>>>
> >>>>>>>>>>>> We do still have the package renaming (GEODE-37) on the
> >>> horizon.
> >>>> My
> >>>>>>>>>>>> suggestion is that in the interests of getting 1.0 out the
> >>> door,
> >>>> at
> >>>>>>>>>> this
> >>>>>>>>>>>> point we should just release geode 1.0 with the old packages
> >>> and
> >>>>>>>>> rename
> >>>>>>>>>>>> packages in geode 2.0.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thoughts?
> >>>>>>>>>>>>
> >>>>>>>>>>>> -Dan
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> ~/William
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> ~/William
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >>
> >> ~/William
> >>
>
>
Re: What will it take to release geode 1.0?
Posted by Anthony Baker <ab...@pivotal.io>.
Thanks Nitin! AFAIK we need new JIRA’s for those issues.
Anthony
> On May 11, 2016, at 11:49 AM, Nitin Lamba <nl...@apache.org> wrote:
>
> Sorry missed this thread last week.
>
> +1 on package-renaming to be picked-up after 1.0 release.
>
> However, the community should try to fix any visible Gemfire references.
> Following are a few I know of:
> (a) Rename Gemfire to Geode on gfsh commands and help (global replace in
> CliStrings class; cleaner way is to use 'format' text using
> GemFireVersion.getProductName)
>
> (b) Rename Gemfire to Geode on JMX end-points (probably rework on JMX,
> management REST, and Pulse)
>
> (c) Renaming gemfire.properties to geode.properties
>
> Does anyone know if there are existing JIRAs for these? If not, I'll create
> new ones and happy to drive at least a few of these for M3.
>
> Thanks,
> Nitin
>
>
> On Tue, May 3, 2016 at 9:19 PM, William Markito <wm...@pivotal.io> wrote:
>
>> Great discussion...
>>
>> On Tue, May 3, 2016 at 6:45 PM, Brian Dunlap <bd...@gmail.com> wrote:
>>
>>> R1 without package renaming sounds good.
>>>
>>
>> Cool.
>>
>>
>>>
>>> Along with the R1 release info, it would be uber-helpful to clarify
>>> cheese-moving public (and internal) API munging that's cooking with R2.
>>>
>>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328142#GeodeModularizationProposal(workinprogress)-Packagenamingscheme
>>>
>>>
>> Some things in this proposal sort of happened with the new layout of the
>> artifacts and sub-modules in Geode, transparent to end users
>> through geode-dependencies.jar, but a lot would be a work in progress while
>> we refactor the code base and may require multiple releases... IHMO.
>>
>>
>>> For example:
>>> Will 2.0 require existing Gemfire clients to bite the
>> com.gemstone.gemfire
>>> bullet? (no yucky package passthrough mappers?)
>>>
>>
>> Now the package rename (and not the artifacts renaming like jar files)
>> could indeed affect GemFire clients but we, at Pivotal, are working on a
>> solution to mitigate (or even completely avoid) that impact.
>>
>>
>>> Does 2.0 include refactored Native Client stuff too?
>>>
>>>
>> That is a good question and I would say that it does make sense given that
>> we would then have a faster release of 1.0.0 without Native Client. - In
>> fact we've started the work /process already and given that the community
>> does accept it we should consider including it on 2.0. But for now, we
>> should probably wait until that process is concluded.
>>
>>
>>>
>>> Thanks,
>>> Brian -
>>>
>>>
>> Thanks for feedback!
>>
>>
>>>
>>> On Tue, May 3, 2016 at 7:07 PM, William Markito <wm...@pivotal.io>
>>> wrote:
>>>
>>>> @Anthony, what if we did:
>>>>
>>>> # M3
>>>> GEODE-1028 Broken website link
>>>> GEODE-1133 SeparateClassloaderTestRunner
>>>> GEODE-1260 Source distribution version info
>>>>
>>>> # 1.0.0
>>>> GEODE-1191 HDFS references
>>>> GEODE-612 Update Jackson version since current version is not on
>> Maven
>>>> central
>>>>
>>>> Reasoning here being that we'd be working on other JSON related items
>> for
>>>> 1.0 as well and to not add much to M3. If you strongly believe it all
>>>> should be in M3, fine as well.. I'm just trying to get M3 out sooner.
>>>>
>>>> @Brian, the current thinking would be to tackle package renaming (and
>> all
>>>> the testing related to it) in the next major release for Geode, making
>>> 1.0
>>>> the release to finalize the migration to ASF - And we would take all
>> the
>>>> lessons learned and efforts to 2.0 which would then come much faster
>>> given
>>>> that we wouldn't have to deal with licensing/clean up, while we learn
>> how
>>>> to release and iterate on new features. 2.0 would also be focusing on
>>>> graduation from incubation... What do you think ?
>>>>
>>>>
>>>> On Tue, May 3, 2016 at 4:50 PM, <bd...@gmail.com> wrote:
>>>>
>>>>> Did Kirk's note about package renaming make the M3 scope? I think it
>>>> would
>>>>> be great to start Geode's 1.0 on a consistent naming standard.
>>>>> :)
>>>>>
>>>>> Pro-Geode!!!
>>>>> Brian -
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>> On May 3, 2016, at 6:09 PM, Anthony Baker <ab...@pivotal.io>
>> wrote:
>>>>>>
>>>>>> William,
>>>>>>
>>>>>> What do you think about including these in M3?
>>>>>>
>>>>>> GEODE-612 Update Jackson version since current version is not on
>>>>> Maven central
>>>>>> GEODE-1028 Broken website link
>>>>>> GEODE-1191 HDFS references
>>>>>> GEODE-1133 SeparateClassloaderTestRunner
>>>>>> GEODE-1260 Source distribution version info
>>>>>>
>>>>>> Anthony
>>>>>>
>>>>>>
>>>>>>> On May 3, 2016, at 3:49 PM, William Markito <wm...@pivotal.io>
>>>>> wrote:
>>>>>>>
>>>>>>> Guys, restarting this thread to get a discussion going about M3,
>>> 1.0.0
>>>>> and
>>>>>>> next - As the release manager for M3 here is what I'd like to
>>>> propose.
>>>>>>>
>>>>>>> Any feedback is welcome and let's also reuse this thread to talk a
>>>>> little
>>>>>>> bit about roadmap as well ?
>>>>>>>
>>>>>>> # Current M3 Scope (
>>>>>>>
>>>>>
>>>>
>>>
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
>>>>>>> )
>>>>>>>
>>>>>>> GEODE-33
>>>>>>> GEODE-823
>>>>>>> GEODE-835
>>>>>>> GEODE-919
>>>>>>> GEODE-1146
>>>>>>> GEODE-1168
>>>>>>> GEODE-1203
>>>>>>> GEODE-1259
>>>>>>> GEODE-1278
>>>>>>> GEODE-1293
>>>>>>> GEODE-1316
>>>>>>> GEODE-1256
>>>>>>> GEODE-1267
>>>>>>>
>>>>>>> == Proposed scope & roadmap ==
>>>>>>>
>>>>>>> I'd like to breakdown the release a little bit and already start
>>>>> planning
>>>>>>> the next releases.
>>>>>>>
>>>>>>> # Geode 1.0.0-incubating M3
>>>>>>>
>>>>>>> GEODE-1316 Update @since tags to include GemFire or Geode in the
>>>> version
>>>>>>> name
>>>>>>> GEODE-1293 Align code and docs for modules
>>>>>>> GEODE-1278 AbstractPeerTXRegionStub should throw
>>>>>>> TransactionDataNodeHasDeparted when remote cache is closed
>>>>>>> GEODE-1267 NOTICE file improvements
>>>>>>> GEODE-1256 Geode website - Unapproved licenses
>>>>>>> GEODE-1203 gfsh connect --use-http reports a
>> ClassNotFoundException
>>>>>>> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5,
>>>> asc.sha1)
>>>>>>> GEODE-835 Replace joptsimple source with a binary dependency
>>>>>>> GEODE-823 RC Feedback: Fix build artifacts
>>>>>>> GEODE-33-1 Create project examples
>>>>>>>
>>>>>>> # Geode 1.0.0-incubating
>>>>>>>
>>>>>>> GEODE-33-2 Create project examples
>>>>>>> GEODE-1331 gfsh.bat on Windows is incorrect
>>>>>>> GEODE-1168 geode-dependencies manifest is missing jars that are
>>>> present
>>>>> in
>>>>>>> the lib directory
>>>>>>> GEODE-629 Replace use of org.json with Jackson JSON library
>>>>>>> GEODE-607 the offheap package needs better unit test coverage
>>>>>>> GEODE-136 Fix possible NullPointerException in Gfsh's 'list
>> regions'
>>>>>>> command's GetRegionsFunction.
>>>>>>>
>>>>>>> # Geode 1.X.0-incubating
>>>>>>>
>>>>>>> GEODE-17 Provide Integrated Security
>>>>>>> GEODE-11 Lucene Integration
>>>>>>> GEODE-33-3 Create project examples
>>>>>>>
>>>>>>> # Geode 2.0.0-incubating
>>>>>>>
>>>>>>> GEODE-72 Remove deprecated APIs from Geode
>>>>>>> GEODE-37 Package renaming
>>>>>>> ---------------------------
>>>>>>>
>>>>>>> Comments:
>>>>>>>
>>>>>>> GEODE-33 would be broken into 3 different tasks, where on M3 we
>>> would
>>>>> start
>>>>>>> with the example structure and a few examples, and incrementally
>> add
>>>>> more
>>>>>>> examples in the next releases.
>>>>>>>
>>>>>>> GEODE-37 is the package rename which due to the huge effort in
>>> testing
>>>>> and
>>>>>>> with the goal to complete the removal of deprecated API's
>> (GEODE-72
>>>> and
>>>>>>> it's sub-tasks) would be pushed to 2.0. This would also allow
>> faster
>>>>>>> releases in 1.0.0 series.
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <
>>>>> niall.pemberton@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I'm not sure if the docs are a prerequisite for graduation. I
>>> don't
>>>>> think
>>>>>>>>> there are specific requirements about the level of documentation
>>> for
>>>>>>>>> graduation, just about community involvement - which docs could
>>> help
>>>>>>>>> encourage :)
>>>>>>>>
>>>>>>>> I think this is a grey area with the user docs being on a vendor
>>>> site.
>>>>>>>> Theres a requirement that "every podling site sources should be
>>>>> maintained
>>>>>>>> in the podling's site SVN or git directory"[1]. Clearly geode
>> meets
>>>>> this to
>>>>>>>> the letter of the law and I've seen other projects websites point
>>> to
>>>>>>>> external resources that are useful. Since theres a plan to donate
>>>> them
>>>>> at
>>>>>>>> some point, my guess is it wouldn't be an issue.
>>>>>>>>
>>>>>>>> [1] http://incubator.apache.org/guides/sites.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> In any case we don't need to graduate or even be graduation
>> ready
>>> to
>>>>>>>>> release 1.0. The version number 1.0 has no special meaning to
>> the
>>>> ASF
>>>>> as
>>>>>>>>> far as I can tell. But I think having regular releases and
>> having
>>> an
>>>>>>>>> official non-milestone release will help us grow the community.
>>>>>>>>
>>>>>>>> A release without a milestone/alpha/beta qualifier is going to
>>>> indicate
>>>>>>>> this community thinks its ready for serious use - so while you're
>>>> right
>>>>>>>> from a ASF perspective, it will have a special meaning for the
>>> wider
>>>>> geode
>>>>>>>> community. And while keeping the existing package names makes the
>>>>>>>> transition easier for existing gemfire users, a package rename
>> in a
>>>>> later
>>>>>>>> version will add pain to the new vast(hopefully!) user base for
>>>> geode.
>>>>> So I
>>>>>>>> would say do it now rather than later.
>>>>>>>>
>>>>>>>> However, if you're going to change the package name, then its
>> also
>>> a
>>>>> good
>>>>>>>> time to remove any deprecated features and correct/change any
>> API's
>>>>> that
>>>>>>>> you're not 100% happy with - which may be alot more work than
>> just
>>>>> changing
>>>>>>>> the package name.
>>>>>>>>
>>>>>>>> Niall
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This page has some information on what's required for
>> graduation:
>>>>>>>>
>>>>>
>>>>
>>>
>> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
>>>>>>>>>
>>>>>>>>> -Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <
>> dbarnes@pivotal.io
>>>>
>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> We plan at some point to donate the docs so they'll be
>>> incorporated
>>>>>>>> into
>>>>>>>>>> the repo. Is this a prerequisite to graduating from incubation?
>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <klund@pivotal.io
>>>
>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> The package renaming would most likely break some backwards
>>>>>>>>> compatibility
>>>>>>>>>>> between 1.0 and 2.0. I'd prefer to see the packages get
>> renamed
>>>>>>>> before
>>>>>>>>>> 1.0
>>>>>>>>>>> so we can change the packages of Message classes, etc in the
>>> same
>>>>>>>>> release
>>>>>>>>>>> that introduces the new JGroups.
>>>>>>>>>>>
>>>>>>>>>>> The packages are currently a mess of com.gemstone.*,
>>> com.vmware.*,
>>>>>>>>>>> joptsimple.*, org.json.* (would we change all four or just the
>>>>>>>>>>> gemstone/vmware packages?).
>>>>>>>>>>>
>>>>>>>>>>> I'm probably biting off more than I should, but I'd be willing
>>>> head
>>>>>>>> up
>>>>>>>>>> the
>>>>>>>>>>> package renaming effort.
>>>>>>>>>>>
>>>>>>>>>>> I think maintaining backwards compatibility (rolling upgrades
>>>>>>>> included)
>>>>>>>>>> for
>>>>>>>>>>> releases following Geode 1.0 is a definite requirement. I'd
>> like
>>>> to
>>>>>>>> see
>>>>>>>>>> the
>>>>>>>>>>> other discussion thread about defining the Geode protocol(s)
>>>>> converge
>>>>>>>>>> with
>>>>>>>>>>> this thread. Officially defining the communication protocols
>>>>>>>> (cluster,
>>>>>>>>>>> client/server, etc) would ideally happen in conjunction with
>> 1.0
>>>> so
>>>>>>>>> that
>>>>>>>>>>> it's concrete and less ambiguous for 2.0 and later releases.
>>>>>>>>>>>
>>>>>>>>>>> -Kirk
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <
>> dsmith@pivotal.io>
>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> We've been releasing milestones of 1.0, but at some point we
>>>>>>>> actually
>>>>>>>>>>> have
>>>>>>>>>>>> to release a real geode 1.0 :)
>>>>>>>>>>>>
>>>>>>>>>>>> What is keeping us from releasing geode 1.0 at this point?
>> Just
>>>> the
>>>>>>>>>>> issues
>>>>>>>>>>>> currently marked with Fix Version M3? I think we should nail
>>> down
>>>>>>>> the
>>>>>>>>>>> scope
>>>>>>>>>>>> of 1.0 and track our progress to the 1.0 release.
>>>>>>>>>>>>
>>>>>>>>>>>> From the apache process perspective, I don't think 1.0 is any
>>>>>>>>> different
>>>>>>>>>>>> from the milestone releases we've done so far. The only
>>>> difference
>>>>>>>>> with
>>>>>>>>>>> 1.0
>>>>>>>>>>>> is what it means to the geode community.
>>>>>>>>>>>>
>>>>>>>>>>>> Gemfire maintained backwards compatibility with previous
>>> releases
>>>>>>>> for
>>>>>>>>>>>> persistent files, client/server, WAN, and P2P messaging. I
>>> think
>>>>>>>> once
>>>>>>>>>> we
>>>>>>>>>>>> release 1.0 we should provide that same guarantee that the
>> next
>>>>>>>> geode
>>>>>>>>>>>> release will be backwards compatible with 1.0.
>>>>>>>>>>>>
>>>>>>>>>>>> We do still have the package renaming (GEODE-37) on the
>>> horizon.
>>>> My
>>>>>>>>>>>> suggestion is that in the interests of getting 1.0 out the
>>> door,
>>>> at
>>>>>>>>>> this
>>>>>>>>>>>> point we should just release geode 1.0 with the old packages
>>> and
>>>>>>>>> rename
>>>>>>>>>>>> packages in geode 2.0.
>>>>>>>>>>>>
>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> -Dan
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> ~/William
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> ~/William
>>>>
>>>
>>
>>
>>
>> --
>>
>> ~/William
>>
Re: What will it take to release geode 1.0?
Posted by Nitin Lamba <nl...@apache.org>.
Sorry missed this thread last week.
+1 on package-renaming to be picked-up after 1.0 release.
However, the community should try to fix any visible Gemfire references.
Following are a few I know of:
(a) Rename Gemfire to Geode on gfsh commands and help (global replace in
CliStrings class; cleaner way is to use 'format' text using
GemFireVersion.getProductName)
(b) Rename Gemfire to Geode on JMX end-points (probably rework on JMX,
management REST, and Pulse)
(c) Renaming gemfire.properties to geode.properties
Does anyone know if there are existing JIRAs for these? If not, I'll create
new ones and happy to drive at least a few of these for M3.
Thanks,
Nitin
On Tue, May 3, 2016 at 9:19 PM, William Markito <wm...@pivotal.io> wrote:
> Great discussion...
>
> On Tue, May 3, 2016 at 6:45 PM, Brian Dunlap <bd...@gmail.com> wrote:
>
> > R1 without package renaming sounds good.
> >
>
> Cool.
>
>
> >
> > Along with the R1 release info, it would be uber-helpful to clarify
> > cheese-moving public (and internal) API munging that's cooking with R2.
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328142#GeodeModularizationProposal(workinprogress)-Packagenamingscheme
> >
> >
> Some things in this proposal sort of happened with the new layout of the
> artifacts and sub-modules in Geode, transparent to end users
> through geode-dependencies.jar, but a lot would be a work in progress while
> we refactor the code base and may require multiple releases... IHMO.
>
>
> > For example:
> > Will 2.0 require existing Gemfire clients to bite the
> com.gemstone.gemfire
> > bullet? (no yucky package passthrough mappers?)
> >
>
> Now the package rename (and not the artifacts renaming like jar files)
> could indeed affect GemFire clients but we, at Pivotal, are working on a
> solution to mitigate (or even completely avoid) that impact.
>
>
> > Does 2.0 include refactored Native Client stuff too?
> >
> >
> That is a good question and I would say that it does make sense given that
> we would then have a faster release of 1.0.0 without Native Client. - In
> fact we've started the work /process already and given that the community
> does accept it we should consider including it on 2.0. But for now, we
> should probably wait until that process is concluded.
>
>
> >
> > Thanks,
> > Brian -
> >
> >
> Thanks for feedback!
>
>
> >
> > On Tue, May 3, 2016 at 7:07 PM, William Markito <wm...@pivotal.io>
> > wrote:
> >
> > > @Anthony, what if we did:
> > >
> > > # M3
> > > GEODE-1028 Broken website link
> > > GEODE-1133 SeparateClassloaderTestRunner
> > > GEODE-1260 Source distribution version info
> > >
> > > # 1.0.0
> > > GEODE-1191 HDFS references
> > > GEODE-612 Update Jackson version since current version is not on
> Maven
> > > central
> > >
> > > Reasoning here being that we'd be working on other JSON related items
> for
> > > 1.0 as well and to not add much to M3. If you strongly believe it all
> > > should be in M3, fine as well.. I'm just trying to get M3 out sooner.
> > >
> > > @Brian, the current thinking would be to tackle package renaming (and
> all
> > > the testing related to it) in the next major release for Geode, making
> > 1.0
> > > the release to finalize the migration to ASF - And we would take all
> the
> > > lessons learned and efforts to 2.0 which would then come much faster
> > given
> > > that we wouldn't have to deal with licensing/clean up, while we learn
> how
> > > to release and iterate on new features. 2.0 would also be focusing on
> > > graduation from incubation... What do you think ?
> > >
> > >
> > > On Tue, May 3, 2016 at 4:50 PM, <bd...@gmail.com> wrote:
> > >
> > > > Did Kirk's note about package renaming make the M3 scope? I think it
> > > would
> > > > be great to start Geode's 1.0 on a consistent naming standard.
> > > > :)
> > > >
> > > > Pro-Geode!!!
> > > > Brian -
> > > >
> > > > Sent from my iPhone
> > > >
> > > > > On May 3, 2016, at 6:09 PM, Anthony Baker <ab...@pivotal.io>
> wrote:
> > > > >
> > > > > William,
> > > > >
> > > > > What do you think about including these in M3?
> > > > >
> > > > > GEODE-612 Update Jackson version since current version is not on
> > > > Maven central
> > > > > GEODE-1028 Broken website link
> > > > > GEODE-1191 HDFS references
> > > > > GEODE-1133 SeparateClassloaderTestRunner
> > > > > GEODE-1260 Source distribution version info
> > > > >
> > > > > Anthony
> > > > >
> > > > >
> > > > >> On May 3, 2016, at 3:49 PM, William Markito <wm...@pivotal.io>
> > > > wrote:
> > > > >>
> > > > >> Guys, restarting this thread to get a discussion going about M3,
> > 1.0.0
> > > > and
> > > > >> next - As the release manager for M3 here is what I'd like to
> > > propose.
> > > > >>
> > > > >> Any feedback is welcome and let's also reuse this thread to talk a
> > > > little
> > > > >> bit about roadmap as well ?
> > > > >>
> > > > >> # Current M3 Scope (
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
> > > > >> )
> > > > >>
> > > > >> GEODE-33
> > > > >> GEODE-823
> > > > >> GEODE-835
> > > > >> GEODE-919
> > > > >> GEODE-1146
> > > > >> GEODE-1168
> > > > >> GEODE-1203
> > > > >> GEODE-1259
> > > > >> GEODE-1278
> > > > >> GEODE-1293
> > > > >> GEODE-1316
> > > > >> GEODE-1256
> > > > >> GEODE-1267
> > > > >>
> > > > >> == Proposed scope & roadmap ==
> > > > >>
> > > > >> I'd like to breakdown the release a little bit and already start
> > > > planning
> > > > >> the next releases.
> > > > >>
> > > > >> # Geode 1.0.0-incubating M3
> > > > >>
> > > > >> GEODE-1316 Update @since tags to include GemFire or Geode in the
> > > version
> > > > >> name
> > > > >> GEODE-1293 Align code and docs for modules
> > > > >> GEODE-1278 AbstractPeerTXRegionStub should throw
> > > > >> TransactionDataNodeHasDeparted when remote cache is closed
> > > > >> GEODE-1267 NOTICE file improvements
> > > > >> GEODE-1256 Geode website - Unapproved licenses
> > > > >> GEODE-1203 gfsh connect --use-http reports a
> ClassNotFoundException
> > > > >> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5,
> > > asc.sha1)
> > > > >> GEODE-835 Replace joptsimple source with a binary dependency
> > > > >> GEODE-823 RC Feedback: Fix build artifacts
> > > > >> GEODE-33-1 Create project examples
> > > > >>
> > > > >> # Geode 1.0.0-incubating
> > > > >>
> > > > >> GEODE-33-2 Create project examples
> > > > >> GEODE-1331 gfsh.bat on Windows is incorrect
> > > > >> GEODE-1168 geode-dependencies manifest is missing jars that are
> > > present
> > > > in
> > > > >> the lib directory
> > > > >> GEODE-629 Replace use of org.json with Jackson JSON library
> > > > >> GEODE-607 the offheap package needs better unit test coverage
> > > > >> GEODE-136 Fix possible NullPointerException in Gfsh's 'list
> regions'
> > > > >> command's GetRegionsFunction.
> > > > >>
> > > > >> # Geode 1.X.0-incubating
> > > > >>
> > > > >> GEODE-17 Provide Integrated Security
> > > > >> GEODE-11 Lucene Integration
> > > > >> GEODE-33-3 Create project examples
> > > > >>
> > > > >> # Geode 2.0.0-incubating
> > > > >>
> > > > >> GEODE-72 Remove deprecated APIs from Geode
> > > > >> GEODE-37 Package renaming
> > > > >> ---------------------------
> > > > >>
> > > > >> Comments:
> > > > >>
> > > > >> GEODE-33 would be broken into 3 different tasks, where on M3 we
> > would
> > > > start
> > > > >> with the example structure and a few examples, and incrementally
> add
> > > > more
> > > > >> examples in the next releases.
> > > > >>
> > > > >> GEODE-37 is the package rename which due to the huge effort in
> > testing
> > > > and
> > > > >> with the goal to complete the removal of deprecated API's
> (GEODE-72
> > > and
> > > > >> it's sub-tasks) would be pushed to 2.0. This would also allow
> faster
> > > > >> releases in 1.0.0 series.
> > > > >>
> > > > >>
> > > > >> Thanks,
> > > > >>
> > > > >> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <
> > > > niall.pemberton@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io>
> > > > wrote:
> > > > >>>>
> > > > >>>> I'm not sure if the docs are a prerequisite for graduation. I
> > don't
> > > > think
> > > > >>>> there are specific requirements about the level of documentation
> > for
> > > > >>>> graduation, just about community involvement - which docs could
> > help
> > > > >>>> encourage :)
> > > > >>>
> > > > >>> I think this is a grey area with the user docs being on a vendor
> > > site.
> > > > >>> Theres a requirement that "every podling site sources should be
> > > > maintained
> > > > >>> in the podling's site SVN or git directory"[1]. Clearly geode
> meets
> > > > this to
> > > > >>> the letter of the law and I've seen other projects websites point
> > to
> > > > >>> external resources that are useful. Since theres a plan to donate
> > > them
> > > > at
> > > > >>> some point, my guess is it wouldn't be an issue.
> > > > >>>
> > > > >>> [1] http://incubator.apache.org/guides/sites.html
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>>> In any case we don't need to graduate or even be graduation
> ready
> > to
> > > > >>>> release 1.0. The version number 1.0 has no special meaning to
> the
> > > ASF
> > > > as
> > > > >>>> far as I can tell. But I think having regular releases and
> having
> > an
> > > > >>>> official non-milestone release will help us grow the community.
> > > > >>>
> > > > >>> A release without a milestone/alpha/beta qualifier is going to
> > > indicate
> > > > >>> this community thinks its ready for serious use - so while you're
> > > right
> > > > >>> from a ASF perspective, it will have a special meaning for the
> > wider
> > > > geode
> > > > >>> community. And while keeping the existing package names makes the
> > > > >>> transition easier for existing gemfire users, a package rename
> in a
> > > > later
> > > > >>> version will add pain to the new vast(hopefully!) user base for
> > > geode.
> > > > So I
> > > > >>> would say do it now rather than later.
> > > > >>>
> > > > >>> However, if you're going to change the package name, then its
> also
> > a
> > > > good
> > > > >>> time to remove any deprecated features and correct/change any
> API's
> > > > that
> > > > >>> you're not 100% happy with - which may be alot more work than
> just
> > > > changing
> > > > >>> the package name.
> > > > >>>
> > > > >>> Niall
> > > > >>>
> > > > >>>
> > > > >>>>
> > > > >>>> This page has some information on what's required for
> graduation:
> > > > >>>
> > > >
> > >
> >
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
> > > > >>>>
> > > > >>>> -Dan
> > > > >>>>
> > > > >>>>
> > > > >>>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <
> dbarnes@pivotal.io
> > >
> > > > wrote:
> > > > >>>>>
> > > > >>>>> We plan at some point to donate the docs so they'll be
> > incorporated
> > > > >>> into
> > > > >>>>> the repo. Is this a prerequisite to graduating from incubation?
> > > > >>>>>
> > > > >>>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <klund@pivotal.io
> >
> > > > wrote:
> > > > >>>>>>
> > > > >>>>>> The package renaming would most likely break some backwards
> > > > >>>> compatibility
> > > > >>>>>> between 1.0 and 2.0. I'd prefer to see the packages get
> renamed
> > > > >>> before
> > > > >>>>> 1.0
> > > > >>>>>> so we can change the packages of Message classes, etc in the
> > same
> > > > >>>> release
> > > > >>>>>> that introduces the new JGroups.
> > > > >>>>>>
> > > > >>>>>> The packages are currently a mess of com.gemstone.*,
> > com.vmware.*,
> > > > >>>>>> joptsimple.*, org.json.* (would we change all four or just the
> > > > >>>>>> gemstone/vmware packages?).
> > > > >>>>>>
> > > > >>>>>> I'm probably biting off more than I should, but I'd be willing
> > > head
> > > > >>> up
> > > > >>>>> the
> > > > >>>>>> package renaming effort.
> > > > >>>>>>
> > > > >>>>>> I think maintaining backwards compatibility (rolling upgrades
> > > > >>> included)
> > > > >>>>> for
> > > > >>>>>> releases following Geode 1.0 is a definite requirement. I'd
> like
> > > to
> > > > >>> see
> > > > >>>>> the
> > > > >>>>>> other discussion thread about defining the Geode protocol(s)
> > > > converge
> > > > >>>>> with
> > > > >>>>>> this thread. Officially defining the communication protocols
> > > > >>> (cluster,
> > > > >>>>>> client/server, etc) would ideally happen in conjunction with
> 1.0
> > > so
> > > > >>>> that
> > > > >>>>>> it's concrete and less ambiguous for 2.0 and later releases.
> > > > >>>>>>
> > > > >>>>>> -Kirk
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <
> dsmith@pivotal.io>
> > > > >>> wrote:
> > > > >>>>>>
> > > > >>>>>>> We've been releasing milestones of 1.0, but at some point we
> > > > >>> actually
> > > > >>>>>> have
> > > > >>>>>>> to release a real geode 1.0 :)
> > > > >>>>>>>
> > > > >>>>>>> What is keeping us from releasing geode 1.0 at this point?
> Just
> > > the
> > > > >>>>>> issues
> > > > >>>>>>> currently marked with Fix Version M3? I think we should nail
> > down
> > > > >>> the
> > > > >>>>>> scope
> > > > >>>>>>> of 1.0 and track our progress to the 1.0 release.
> > > > >>>>>>>
> > > > >>>>>>> From the apache process perspective, I don't think 1.0 is any
> > > > >>>> different
> > > > >>>>>>> from the milestone releases we've done so far. The only
> > > difference
> > > > >>>> with
> > > > >>>>>> 1.0
> > > > >>>>>>> is what it means to the geode community.
> > > > >>>>>>>
> > > > >>>>>>> Gemfire maintained backwards compatibility with previous
> > releases
> > > > >>> for
> > > > >>>>>>> persistent files, client/server, WAN, and P2P messaging. I
> > think
> > > > >>> once
> > > > >>>>> we
> > > > >>>>>>> release 1.0 we should provide that same guarantee that the
> next
> > > > >>> geode
> > > > >>>>>>> release will be backwards compatible with 1.0.
> > > > >>>>>>>
> > > > >>>>>>> We do still have the package renaming (GEODE-37) on the
> > horizon.
> > > My
> > > > >>>>>>> suggestion is that in the interests of getting 1.0 out the
> > door,
> > > at
> > > > >>>>> this
> > > > >>>>>>> point we should just release geode 1.0 with the old packages
> > and
> > > > >>>> rename
> > > > >>>>>>> packages in geode 2.0.
> > > > >>>>>>>
> > > > >>>>>>> Thoughts?
> > > > >>>>>>>
> > > > >>>>>>> -Dan
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >>
> > > > >> ~/William
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > ~/William
> > >
> >
>
>
>
> --
>
> ~/William
>
Re: What will it take to release geode 1.0?
Posted by William Markito <wm...@pivotal.io>.
Great discussion...
On Tue, May 3, 2016 at 6:45 PM, Brian Dunlap <bd...@gmail.com> wrote:
> R1 without package renaming sounds good.
>
Cool.
>
> Along with the R1 release info, it would be uber-helpful to clarify
> cheese-moving public (and internal) API munging that's cooking with R2.
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328142#GeodeModularizationProposal(workinprogress)-Packagenamingscheme
>
>
Some things in this proposal sort of happened with the new layout of the
artifacts and sub-modules in Geode, transparent to end users
through geode-dependencies.jar, but a lot would be a work in progress while
we refactor the code base and may require multiple releases... IHMO.
> For example:
> Will 2.0 require existing Gemfire clients to bite the com.gemstone.gemfire
> bullet? (no yucky package passthrough mappers?)
>
Now the package rename (and not the artifacts renaming like jar files)
could indeed affect GemFire clients but we, at Pivotal, are working on a
solution to mitigate (or even completely avoid) that impact.
> Does 2.0 include refactored Native Client stuff too?
>
>
That is a good question and I would say that it does make sense given that
we would then have a faster release of 1.0.0 without Native Client. - In
fact we've started the work /process already and given that the community
does accept it we should consider including it on 2.0. But for now, we
should probably wait until that process is concluded.
>
> Thanks,
> Brian -
>
>
Thanks for feedback!
>
> On Tue, May 3, 2016 at 7:07 PM, William Markito <wm...@pivotal.io>
> wrote:
>
> > @Anthony, what if we did:
> >
> > # M3
> > GEODE-1028 Broken website link
> > GEODE-1133 SeparateClassloaderTestRunner
> > GEODE-1260 Source distribution version info
> >
> > # 1.0.0
> > GEODE-1191 HDFS references
> > GEODE-612 Update Jackson version since current version is not on Maven
> > central
> >
> > Reasoning here being that we'd be working on other JSON related items for
> > 1.0 as well and to not add much to M3. If you strongly believe it all
> > should be in M3, fine as well.. I'm just trying to get M3 out sooner.
> >
> > @Brian, the current thinking would be to tackle package renaming (and all
> > the testing related to it) in the next major release for Geode, making
> 1.0
> > the release to finalize the migration to ASF - And we would take all the
> > lessons learned and efforts to 2.0 which would then come much faster
> given
> > that we wouldn't have to deal with licensing/clean up, while we learn how
> > to release and iterate on new features. 2.0 would also be focusing on
> > graduation from incubation... What do you think ?
> >
> >
> > On Tue, May 3, 2016 at 4:50 PM, <bd...@gmail.com> wrote:
> >
> > > Did Kirk's note about package renaming make the M3 scope? I think it
> > would
> > > be great to start Geode's 1.0 on a consistent naming standard.
> > > :)
> > >
> > > Pro-Geode!!!
> > > Brian -
> > >
> > > Sent from my iPhone
> > >
> > > > On May 3, 2016, at 6:09 PM, Anthony Baker <ab...@pivotal.io> wrote:
> > > >
> > > > William,
> > > >
> > > > What do you think about including these in M3?
> > > >
> > > > GEODE-612 Update Jackson version since current version is not on
> > > Maven central
> > > > GEODE-1028 Broken website link
> > > > GEODE-1191 HDFS references
> > > > GEODE-1133 SeparateClassloaderTestRunner
> > > > GEODE-1260 Source distribution version info
> > > >
> > > > Anthony
> > > >
> > > >
> > > >> On May 3, 2016, at 3:49 PM, William Markito <wm...@pivotal.io>
> > > wrote:
> > > >>
> > > >> Guys, restarting this thread to get a discussion going about M3,
> 1.0.0
> > > and
> > > >> next - As the release manager for M3 here is what I'd like to
> > propose.
> > > >>
> > > >> Any feedback is welcome and let's also reuse this thread to talk a
> > > little
> > > >> bit about roadmap as well ?
> > > >>
> > > >> # Current M3 Scope (
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
> > > >> )
> > > >>
> > > >> GEODE-33
> > > >> GEODE-823
> > > >> GEODE-835
> > > >> GEODE-919
> > > >> GEODE-1146
> > > >> GEODE-1168
> > > >> GEODE-1203
> > > >> GEODE-1259
> > > >> GEODE-1278
> > > >> GEODE-1293
> > > >> GEODE-1316
> > > >> GEODE-1256
> > > >> GEODE-1267
> > > >>
> > > >> == Proposed scope & roadmap ==
> > > >>
> > > >> I'd like to breakdown the release a little bit and already start
> > > planning
> > > >> the next releases.
> > > >>
> > > >> # Geode 1.0.0-incubating M3
> > > >>
> > > >> GEODE-1316 Update @since tags to include GemFire or Geode in the
> > version
> > > >> name
> > > >> GEODE-1293 Align code and docs for modules
> > > >> GEODE-1278 AbstractPeerTXRegionStub should throw
> > > >> TransactionDataNodeHasDeparted when remote cache is closed
> > > >> GEODE-1267 NOTICE file improvements
> > > >> GEODE-1256 Geode website - Unapproved licenses
> > > >> GEODE-1203 gfsh connect --use-http reports a ClassNotFoundException
> > > >> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5,
> > asc.sha1)
> > > >> GEODE-835 Replace joptsimple source with a binary dependency
> > > >> GEODE-823 RC Feedback: Fix build artifacts
> > > >> GEODE-33-1 Create project examples
> > > >>
> > > >> # Geode 1.0.0-incubating
> > > >>
> > > >> GEODE-33-2 Create project examples
> > > >> GEODE-1331 gfsh.bat on Windows is incorrect
> > > >> GEODE-1168 geode-dependencies manifest is missing jars that are
> > present
> > > in
> > > >> the lib directory
> > > >> GEODE-629 Replace use of org.json with Jackson JSON library
> > > >> GEODE-607 the offheap package needs better unit test coverage
> > > >> GEODE-136 Fix possible NullPointerException in Gfsh's 'list regions'
> > > >> command's GetRegionsFunction.
> > > >>
> > > >> # Geode 1.X.0-incubating
> > > >>
> > > >> GEODE-17 Provide Integrated Security
> > > >> GEODE-11 Lucene Integration
> > > >> GEODE-33-3 Create project examples
> > > >>
> > > >> # Geode 2.0.0-incubating
> > > >>
> > > >> GEODE-72 Remove deprecated APIs from Geode
> > > >> GEODE-37 Package renaming
> > > >> ---------------------------
> > > >>
> > > >> Comments:
> > > >>
> > > >> GEODE-33 would be broken into 3 different tasks, where on M3 we
> would
> > > start
> > > >> with the example structure and a few examples, and incrementally add
> > > more
> > > >> examples in the next releases.
> > > >>
> > > >> GEODE-37 is the package rename which due to the huge effort in
> testing
> > > and
> > > >> with the goal to complete the removal of deprecated API's (GEODE-72
> > and
> > > >> it's sub-tasks) would be pushed to 2.0. This would also allow faster
> > > >> releases in 1.0.0 series.
> > > >>
> > > >>
> > > >> Thanks,
> > > >>
> > > >> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <
> > > niall.pemberton@gmail.com>
> > > >> wrote:
> > > >>
> > > >>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io>
> > > wrote:
> > > >>>>
> > > >>>> I'm not sure if the docs are a prerequisite for graduation. I
> don't
> > > think
> > > >>>> there are specific requirements about the level of documentation
> for
> > > >>>> graduation, just about community involvement - which docs could
> help
> > > >>>> encourage :)
> > > >>>
> > > >>> I think this is a grey area with the user docs being on a vendor
> > site.
> > > >>> Theres a requirement that "every podling site sources should be
> > > maintained
> > > >>> in the podling's site SVN or git directory"[1]. Clearly geode meets
> > > this to
> > > >>> the letter of the law and I've seen other projects websites point
> to
> > > >>> external resources that are useful. Since theres a plan to donate
> > them
> > > at
> > > >>> some point, my guess is it wouldn't be an issue.
> > > >>>
> > > >>> [1] http://incubator.apache.org/guides/sites.html
> > > >>>
> > > >>>
> > > >>>
> > > >>>> In any case we don't need to graduate or even be graduation ready
> to
> > > >>>> release 1.0. The version number 1.0 has no special meaning to the
> > ASF
> > > as
> > > >>>> far as I can tell. But I think having regular releases and having
> an
> > > >>>> official non-milestone release will help us grow the community.
> > > >>>
> > > >>> A release without a milestone/alpha/beta qualifier is going to
> > indicate
> > > >>> this community thinks its ready for serious use - so while you're
> > right
> > > >>> from a ASF perspective, it will have a special meaning for the
> wider
> > > geode
> > > >>> community. And while keeping the existing package names makes the
> > > >>> transition easier for existing gemfire users, a package rename in a
> > > later
> > > >>> version will add pain to the new vast(hopefully!) user base for
> > geode.
> > > So I
> > > >>> would say do it now rather than later.
> > > >>>
> > > >>> However, if you're going to change the package name, then its also
> a
> > > good
> > > >>> time to remove any deprecated features and correct/change any API's
> > > that
> > > >>> you're not 100% happy with - which may be alot more work than just
> > > changing
> > > >>> the package name.
> > > >>>
> > > >>> Niall
> > > >>>
> > > >>>
> > > >>>>
> > > >>>> This page has some information on what's required for graduation:
> > > >>>
> > >
> >
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
> > > >>>>
> > > >>>> -Dan
> > > >>>>
> > > >>>>
> > > >>>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <dbarnes@pivotal.io
> >
> > > wrote:
> > > >>>>>
> > > >>>>> We plan at some point to donate the docs so they'll be
> incorporated
> > > >>> into
> > > >>>>> the repo. Is this a prerequisite to graduating from incubation?
> > > >>>>>
> > > >>>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <kl...@pivotal.io>
> > > wrote:
> > > >>>>>>
> > > >>>>>> The package renaming would most likely break some backwards
> > > >>>> compatibility
> > > >>>>>> between 1.0 and 2.0. I'd prefer to see the packages get renamed
> > > >>> before
> > > >>>>> 1.0
> > > >>>>>> so we can change the packages of Message classes, etc in the
> same
> > > >>>> release
> > > >>>>>> that introduces the new JGroups.
> > > >>>>>>
> > > >>>>>> The packages are currently a mess of com.gemstone.*,
> com.vmware.*,
> > > >>>>>> joptsimple.*, org.json.* (would we change all four or just the
> > > >>>>>> gemstone/vmware packages?).
> > > >>>>>>
> > > >>>>>> I'm probably biting off more than I should, but I'd be willing
> > head
> > > >>> up
> > > >>>>> the
> > > >>>>>> package renaming effort.
> > > >>>>>>
> > > >>>>>> I think maintaining backwards compatibility (rolling upgrades
> > > >>> included)
> > > >>>>> for
> > > >>>>>> releases following Geode 1.0 is a definite requirement. I'd like
> > to
> > > >>> see
> > > >>>>> the
> > > >>>>>> other discussion thread about defining the Geode protocol(s)
> > > converge
> > > >>>>> with
> > > >>>>>> this thread. Officially defining the communication protocols
> > > >>> (cluster,
> > > >>>>>> client/server, etc) would ideally happen in conjunction with 1.0
> > so
> > > >>>> that
> > > >>>>>> it's concrete and less ambiguous for 2.0 and later releases.
> > > >>>>>>
> > > >>>>>> -Kirk
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <ds...@pivotal.io>
> > > >>> wrote:
> > > >>>>>>
> > > >>>>>>> We've been releasing milestones of 1.0, but at some point we
> > > >>> actually
> > > >>>>>> have
> > > >>>>>>> to release a real geode 1.0 :)
> > > >>>>>>>
> > > >>>>>>> What is keeping us from releasing geode 1.0 at this point? Just
> > the
> > > >>>>>> issues
> > > >>>>>>> currently marked with Fix Version M3? I think we should nail
> down
> > > >>> the
> > > >>>>>> scope
> > > >>>>>>> of 1.0 and track our progress to the 1.0 release.
> > > >>>>>>>
> > > >>>>>>> From the apache process perspective, I don't think 1.0 is any
> > > >>>> different
> > > >>>>>>> from the milestone releases we've done so far. The only
> > difference
> > > >>>> with
> > > >>>>>> 1.0
> > > >>>>>>> is what it means to the geode community.
> > > >>>>>>>
> > > >>>>>>> Gemfire maintained backwards compatibility with previous
> releases
> > > >>> for
> > > >>>>>>> persistent files, client/server, WAN, and P2P messaging. I
> think
> > > >>> once
> > > >>>>> we
> > > >>>>>>> release 1.0 we should provide that same guarantee that the next
> > > >>> geode
> > > >>>>>>> release will be backwards compatible with 1.0.
> > > >>>>>>>
> > > >>>>>>> We do still have the package renaming (GEODE-37) on the
> horizon.
> > My
> > > >>>>>>> suggestion is that in the interests of getting 1.0 out the
> door,
> > at
> > > >>>>> this
> > > >>>>>>> point we should just release geode 1.0 with the old packages
> and
> > > >>>> rename
> > > >>>>>>> packages in geode 2.0.
> > > >>>>>>>
> > > >>>>>>> Thoughts?
> > > >>>>>>>
> > > >>>>>>> -Dan
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> ~/William
> > > >
> > >
> >
> >
> >
> > --
> >
> > ~/William
> >
>
--
~/William
Re: What will it take to release geode 1.0?
Posted by Brian Dunlap <bd...@gmail.com>.
R1 without package renaming sounds good.
Along with the R1 release info, it would be uber-helpful to clarify
cheese-moving public (and internal) API munging that's cooking with R2.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328142#GeodeModularizationProposal(workinprogress)-Packagenamingscheme
For example:
Will 2.0 require existing Gemfire clients to bite the com.gemstone.gemfire
bullet? (no yucky package passthrough mappers?)
Does 2.0 include refactored Native Client stuff too?
Thanks,
Brian -
On Tue, May 3, 2016 at 7:07 PM, William Markito <wm...@pivotal.io> wrote:
> @Anthony, what if we did:
>
> # M3
> GEODE-1028 Broken website link
> GEODE-1133 SeparateClassloaderTestRunner
> GEODE-1260 Source distribution version info
>
> # 1.0.0
> GEODE-1191 HDFS references
> GEODE-612 Update Jackson version since current version is not on Maven
> central
>
> Reasoning here being that we'd be working on other JSON related items for
> 1.0 as well and to not add much to M3. If you strongly believe it all
> should be in M3, fine as well.. I'm just trying to get M3 out sooner.
>
> @Brian, the current thinking would be to tackle package renaming (and all
> the testing related to it) in the next major release for Geode, making 1.0
> the release to finalize the migration to ASF - And we would take all the
> lessons learned and efforts to 2.0 which would then come much faster given
> that we wouldn't have to deal with licensing/clean up, while we learn how
> to release and iterate on new features. 2.0 would also be focusing on
> graduation from incubation... What do you think ?
>
>
> On Tue, May 3, 2016 at 4:50 PM, <bd...@gmail.com> wrote:
>
> > Did Kirk's note about package renaming make the M3 scope? I think it
> would
> > be great to start Geode's 1.0 on a consistent naming standard.
> > :)
> >
> > Pro-Geode!!!
> > Brian -
> >
> > Sent from my iPhone
> >
> > > On May 3, 2016, at 6:09 PM, Anthony Baker <ab...@pivotal.io> wrote:
> > >
> > > William,
> > >
> > > What do you think about including these in M3?
> > >
> > > GEODE-612 Update Jackson version since current version is not on
> > Maven central
> > > GEODE-1028 Broken website link
> > > GEODE-1191 HDFS references
> > > GEODE-1133 SeparateClassloaderTestRunner
> > > GEODE-1260 Source distribution version info
> > >
> > > Anthony
> > >
> > >
> > >> On May 3, 2016, at 3:49 PM, William Markito <wm...@pivotal.io>
> > wrote:
> > >>
> > >> Guys, restarting this thread to get a discussion going about M3, 1.0.0
> > and
> > >> next - As the release manager for M3 here is what I'd like to
> propose.
> > >>
> > >> Any feedback is welcome and let's also reuse this thread to talk a
> > little
> > >> bit about roadmap as well ?
> > >>
> > >> # Current M3 Scope (
> > >>
> >
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
> > >> )
> > >>
> > >> GEODE-33
> > >> GEODE-823
> > >> GEODE-835
> > >> GEODE-919
> > >> GEODE-1146
> > >> GEODE-1168
> > >> GEODE-1203
> > >> GEODE-1259
> > >> GEODE-1278
> > >> GEODE-1293
> > >> GEODE-1316
> > >> GEODE-1256
> > >> GEODE-1267
> > >>
> > >> == Proposed scope & roadmap ==
> > >>
> > >> I'd like to breakdown the release a little bit and already start
> > planning
> > >> the next releases.
> > >>
> > >> # Geode 1.0.0-incubating M3
> > >>
> > >> GEODE-1316 Update @since tags to include GemFire or Geode in the
> version
> > >> name
> > >> GEODE-1293 Align code and docs for modules
> > >> GEODE-1278 AbstractPeerTXRegionStub should throw
> > >> TransactionDataNodeHasDeparted when remote cache is closed
> > >> GEODE-1267 NOTICE file improvements
> > >> GEODE-1256 Geode website - Unapproved licenses
> > >> GEODE-1203 gfsh connect --use-http reports a ClassNotFoundException
> > >> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5,
> asc.sha1)
> > >> GEODE-835 Replace joptsimple source with a binary dependency
> > >> GEODE-823 RC Feedback: Fix build artifacts
> > >> GEODE-33-1 Create project examples
> > >>
> > >> # Geode 1.0.0-incubating
> > >>
> > >> GEODE-33-2 Create project examples
> > >> GEODE-1331 gfsh.bat on Windows is incorrect
> > >> GEODE-1168 geode-dependencies manifest is missing jars that are
> present
> > in
> > >> the lib directory
> > >> GEODE-629 Replace use of org.json with Jackson JSON library
> > >> GEODE-607 the offheap package needs better unit test coverage
> > >> GEODE-136 Fix possible NullPointerException in Gfsh's 'list regions'
> > >> command's GetRegionsFunction.
> > >>
> > >> # Geode 1.X.0-incubating
> > >>
> > >> GEODE-17 Provide Integrated Security
> > >> GEODE-11 Lucene Integration
> > >> GEODE-33-3 Create project examples
> > >>
> > >> # Geode 2.0.0-incubating
> > >>
> > >> GEODE-72 Remove deprecated APIs from Geode
> > >> GEODE-37 Package renaming
> > >> ---------------------------
> > >>
> > >> Comments:
> > >>
> > >> GEODE-33 would be broken into 3 different tasks, where on M3 we would
> > start
> > >> with the example structure and a few examples, and incrementally add
> > more
> > >> examples in the next releases.
> > >>
> > >> GEODE-37 is the package rename which due to the huge effort in testing
> > and
> > >> with the goal to complete the removal of deprecated API's (GEODE-72
> and
> > >> it's sub-tasks) would be pushed to 2.0. This would also allow faster
> > >> releases in 1.0.0 series.
> > >>
> > >>
> > >> Thanks,
> > >>
> > >> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <
> > niall.pemberton@gmail.com>
> > >> wrote:
> > >>
> > >>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io>
> > wrote:
> > >>>>
> > >>>> I'm not sure if the docs are a prerequisite for graduation. I don't
> > think
> > >>>> there are specific requirements about the level of documentation for
> > >>>> graduation, just about community involvement - which docs could help
> > >>>> encourage :)
> > >>>
> > >>> I think this is a grey area with the user docs being on a vendor
> site.
> > >>> Theres a requirement that "every podling site sources should be
> > maintained
> > >>> in the podling's site SVN or git directory"[1]. Clearly geode meets
> > this to
> > >>> the letter of the law and I've seen other projects websites point to
> > >>> external resources that are useful. Since theres a plan to donate
> them
> > at
> > >>> some point, my guess is it wouldn't be an issue.
> > >>>
> > >>> [1] http://incubator.apache.org/guides/sites.html
> > >>>
> > >>>
> > >>>
> > >>>> In any case we don't need to graduate or even be graduation ready to
> > >>>> release 1.0. The version number 1.0 has no special meaning to the
> ASF
> > as
> > >>>> far as I can tell. But I think having regular releases and having an
> > >>>> official non-milestone release will help us grow the community.
> > >>>
> > >>> A release without a milestone/alpha/beta qualifier is going to
> indicate
> > >>> this community thinks its ready for serious use - so while you're
> right
> > >>> from a ASF perspective, it will have a special meaning for the wider
> > geode
> > >>> community. And while keeping the existing package names makes the
> > >>> transition easier for existing gemfire users, a package rename in a
> > later
> > >>> version will add pain to the new vast(hopefully!) user base for
> geode.
> > So I
> > >>> would say do it now rather than later.
> > >>>
> > >>> However, if you're going to change the package name, then its also a
> > good
> > >>> time to remove any deprecated features and correct/change any API's
> > that
> > >>> you're not 100% happy with - which may be alot more work than just
> > changing
> > >>> the package name.
> > >>>
> > >>> Niall
> > >>>
> > >>>
> > >>>>
> > >>>> This page has some information on what's required for graduation:
> > >>>
> >
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
> > >>>>
> > >>>> -Dan
> > >>>>
> > >>>>
> > >>>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <db...@pivotal.io>
> > wrote:
> > >>>>>
> > >>>>> We plan at some point to donate the docs so they'll be incorporated
> > >>> into
> > >>>>> the repo. Is this a prerequisite to graduating from incubation?
> > >>>>>
> > >>>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <kl...@pivotal.io>
> > wrote:
> > >>>>>>
> > >>>>>> The package renaming would most likely break some backwards
> > >>>> compatibility
> > >>>>>> between 1.0 and 2.0. I'd prefer to see the packages get renamed
> > >>> before
> > >>>>> 1.0
> > >>>>>> so we can change the packages of Message classes, etc in the same
> > >>>> release
> > >>>>>> that introduces the new JGroups.
> > >>>>>>
> > >>>>>> The packages are currently a mess of com.gemstone.*, com.vmware.*,
> > >>>>>> joptsimple.*, org.json.* (would we change all four or just the
> > >>>>>> gemstone/vmware packages?).
> > >>>>>>
> > >>>>>> I'm probably biting off more than I should, but I'd be willing
> head
> > >>> up
> > >>>>> the
> > >>>>>> package renaming effort.
> > >>>>>>
> > >>>>>> I think maintaining backwards compatibility (rolling upgrades
> > >>> included)
> > >>>>> for
> > >>>>>> releases following Geode 1.0 is a definite requirement. I'd like
> to
> > >>> see
> > >>>>> the
> > >>>>>> other discussion thread about defining the Geode protocol(s)
> > converge
> > >>>>> with
> > >>>>>> this thread. Officially defining the communication protocols
> > >>> (cluster,
> > >>>>>> client/server, etc) would ideally happen in conjunction with 1.0
> so
> > >>>> that
> > >>>>>> it's concrete and less ambiguous for 2.0 and later releases.
> > >>>>>>
> > >>>>>> -Kirk
> > >>>>>>
> > >>>>>>
> > >>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <ds...@pivotal.io>
> > >>> wrote:
> > >>>>>>
> > >>>>>>> We've been releasing milestones of 1.0, but at some point we
> > >>> actually
> > >>>>>> have
> > >>>>>>> to release a real geode 1.0 :)
> > >>>>>>>
> > >>>>>>> What is keeping us from releasing geode 1.0 at this point? Just
> the
> > >>>>>> issues
> > >>>>>>> currently marked with Fix Version M3? I think we should nail down
> > >>> the
> > >>>>>> scope
> > >>>>>>> of 1.0 and track our progress to the 1.0 release.
> > >>>>>>>
> > >>>>>>> From the apache process perspective, I don't think 1.0 is any
> > >>>> different
> > >>>>>>> from the milestone releases we've done so far. The only
> difference
> > >>>> with
> > >>>>>> 1.0
> > >>>>>>> is what it means to the geode community.
> > >>>>>>>
> > >>>>>>> Gemfire maintained backwards compatibility with previous releases
> > >>> for
> > >>>>>>> persistent files, client/server, WAN, and P2P messaging. I think
> > >>> once
> > >>>>> we
> > >>>>>>> release 1.0 we should provide that same guarantee that the next
> > >>> geode
> > >>>>>>> release will be backwards compatible with 1.0.
> > >>>>>>>
> > >>>>>>> We do still have the package renaming (GEODE-37) on the horizon.
> My
> > >>>>>>> suggestion is that in the interests of getting 1.0 out the door,
> at
> > >>>>> this
> > >>>>>>> point we should just release geode 1.0 with the old packages and
> > >>>> rename
> > >>>>>>> packages in geode 2.0.
> > >>>>>>>
> > >>>>>>> Thoughts?
> > >>>>>>>
> > >>>>>>> -Dan
> > >>
> > >>
> > >>
> > >> --
> > >>
> > >> ~/William
> > >
> >
>
>
>
> --
>
> ~/William
>
Re: What will it take to release geode 1.0?
Posted by Anthony Baker <ab...@pivotal.io>.
Seems fine. I just double-checked and jackson v2.2.0 does seem to be still available on maven central so perhaps GEODE-612 can be closed entirely.
Anthony
> On May 3, 2016, at 5:07 PM, William Markito <wm...@pivotal.io> wrote:
>
> @Anthony, what if we did:
>
> # M3
> GEODE-1028 Broken website link
> GEODE-1133 SeparateClassloaderTestRunner
> GEODE-1260 Source distribution version info
>
> # 1.0.0
> GEODE-1191 HDFS references
> GEODE-612 Update Jackson version since current version is not on Maven
> central
>
> Reasoning here being that we'd be working on other JSON related items for
> 1.0 as well and to not add much to M3. If you strongly believe it all
> should be in M3, fine as well.. I'm just trying to get M3 out sooner.
Re: What will it take to release geode 1.0?
Posted by William Markito <wm...@pivotal.io>.
@Anthony, what if we did:
# M3
GEODE-1028 Broken website link
GEODE-1133 SeparateClassloaderTestRunner
GEODE-1260 Source distribution version info
# 1.0.0
GEODE-1191 HDFS references
GEODE-612 Update Jackson version since current version is not on Maven
central
Reasoning here being that we'd be working on other JSON related items for
1.0 as well and to not add much to M3. If you strongly believe it all
should be in M3, fine as well.. I'm just trying to get M3 out sooner.
@Brian, the current thinking would be to tackle package renaming (and all
the testing related to it) in the next major release for Geode, making 1.0
the release to finalize the migration to ASF - And we would take all the
lessons learned and efforts to 2.0 which would then come much faster given
that we wouldn't have to deal with licensing/clean up, while we learn how
to release and iterate on new features. 2.0 would also be focusing on
graduation from incubation... What do you think ?
On Tue, May 3, 2016 at 4:50 PM, <bd...@gmail.com> wrote:
> Did Kirk's note about package renaming make the M3 scope? I think it would
> be great to start Geode's 1.0 on a consistent naming standard.
> :)
>
> Pro-Geode!!!
> Brian -
>
> Sent from my iPhone
>
> > On May 3, 2016, at 6:09 PM, Anthony Baker <ab...@pivotal.io> wrote:
> >
> > William,
> >
> > What do you think about including these in M3?
> >
> > GEODE-612 Update Jackson version since current version is not on
> Maven central
> > GEODE-1028 Broken website link
> > GEODE-1191 HDFS references
> > GEODE-1133 SeparateClassloaderTestRunner
> > GEODE-1260 Source distribution version info
> >
> > Anthony
> >
> >
> >> On May 3, 2016, at 3:49 PM, William Markito <wm...@pivotal.io>
> wrote:
> >>
> >> Guys, restarting this thread to get a discussion going about M3, 1.0.0
> and
> >> next - As the release manager for M3 here is what I'd like to propose.
> >>
> >> Any feedback is welcome and let's also reuse this thread to talk a
> little
> >> bit about roadmap as well ?
> >>
> >> # Current M3 Scope (
> >>
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
> >> )
> >>
> >> GEODE-33
> >> GEODE-823
> >> GEODE-835
> >> GEODE-919
> >> GEODE-1146
> >> GEODE-1168
> >> GEODE-1203
> >> GEODE-1259
> >> GEODE-1278
> >> GEODE-1293
> >> GEODE-1316
> >> GEODE-1256
> >> GEODE-1267
> >>
> >> == Proposed scope & roadmap ==
> >>
> >> I'd like to breakdown the release a little bit and already start
> planning
> >> the next releases.
> >>
> >> # Geode 1.0.0-incubating M3
> >>
> >> GEODE-1316 Update @since tags to include GemFire or Geode in the version
> >> name
> >> GEODE-1293 Align code and docs for modules
> >> GEODE-1278 AbstractPeerTXRegionStub should throw
> >> TransactionDataNodeHasDeparted when remote cache is closed
> >> GEODE-1267 NOTICE file improvements
> >> GEODE-1256 Geode website - Unapproved licenses
> >> GEODE-1203 gfsh connect --use-http reports a ClassNotFoundException
> >> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, asc.sha1)
> >> GEODE-835 Replace joptsimple source with a binary dependency
> >> GEODE-823 RC Feedback: Fix build artifacts
> >> GEODE-33-1 Create project examples
> >>
> >> # Geode 1.0.0-incubating
> >>
> >> GEODE-33-2 Create project examples
> >> GEODE-1331 gfsh.bat on Windows is incorrect
> >> GEODE-1168 geode-dependencies manifest is missing jars that are present
> in
> >> the lib directory
> >> GEODE-629 Replace use of org.json with Jackson JSON library
> >> GEODE-607 the offheap package needs better unit test coverage
> >> GEODE-136 Fix possible NullPointerException in Gfsh's 'list regions'
> >> command's GetRegionsFunction.
> >>
> >> # Geode 1.X.0-incubating
> >>
> >> GEODE-17 Provide Integrated Security
> >> GEODE-11 Lucene Integration
> >> GEODE-33-3 Create project examples
> >>
> >> # Geode 2.0.0-incubating
> >>
> >> GEODE-72 Remove deprecated APIs from Geode
> >> GEODE-37 Package renaming
> >> ---------------------------
> >>
> >> Comments:
> >>
> >> GEODE-33 would be broken into 3 different tasks, where on M3 we would
> start
> >> with the example structure and a few examples, and incrementally add
> more
> >> examples in the next releases.
> >>
> >> GEODE-37 is the package rename which due to the huge effort in testing
> and
> >> with the goal to complete the removal of deprecated API's (GEODE-72 and
> >> it's sub-tasks) would be pushed to 2.0. This would also allow faster
> >> releases in 1.0.0 series.
> >>
> >>
> >> Thanks,
> >>
> >> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <
> niall.pemberton@gmail.com>
> >> wrote:
> >>
> >>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io>
> wrote:
> >>>>
> >>>> I'm not sure if the docs are a prerequisite for graduation. I don't
> think
> >>>> there are specific requirements about the level of documentation for
> >>>> graduation, just about community involvement - which docs could help
> >>>> encourage :)
> >>>
> >>> I think this is a grey area with the user docs being on a vendor site.
> >>> Theres a requirement that "every podling site sources should be
> maintained
> >>> in the podling's site SVN or git directory"[1]. Clearly geode meets
> this to
> >>> the letter of the law and I've seen other projects websites point to
> >>> external resources that are useful. Since theres a plan to donate them
> at
> >>> some point, my guess is it wouldn't be an issue.
> >>>
> >>> [1] http://incubator.apache.org/guides/sites.html
> >>>
> >>>
> >>>
> >>>> In any case we don't need to graduate or even be graduation ready to
> >>>> release 1.0. The version number 1.0 has no special meaning to the ASF
> as
> >>>> far as I can tell. But I think having regular releases and having an
> >>>> official non-milestone release will help us grow the community.
> >>>
> >>> A release without a milestone/alpha/beta qualifier is going to indicate
> >>> this community thinks its ready for serious use - so while you're right
> >>> from a ASF perspective, it will have a special meaning for the wider
> geode
> >>> community. And while keeping the existing package names makes the
> >>> transition easier for existing gemfire users, a package rename in a
> later
> >>> version will add pain to the new vast(hopefully!) user base for geode.
> So I
> >>> would say do it now rather than later.
> >>>
> >>> However, if you're going to change the package name, then its also a
> good
> >>> time to remove any deprecated features and correct/change any API's
> that
> >>> you're not 100% happy with - which may be alot more work than just
> changing
> >>> the package name.
> >>>
> >>> Niall
> >>>
> >>>
> >>>>
> >>>> This page has some information on what's required for graduation:
> >>>
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
> >>>>
> >>>> -Dan
> >>>>
> >>>>
> >>>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <db...@pivotal.io>
> wrote:
> >>>>>
> >>>>> We plan at some point to donate the docs so they'll be incorporated
> >>> into
> >>>>> the repo. Is this a prerequisite to graduating from incubation?
> >>>>>
> >>>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <kl...@pivotal.io>
> wrote:
> >>>>>>
> >>>>>> The package renaming would most likely break some backwards
> >>>> compatibility
> >>>>>> between 1.0 and 2.0. I'd prefer to see the packages get renamed
> >>> before
> >>>>> 1.0
> >>>>>> so we can change the packages of Message classes, etc in the same
> >>>> release
> >>>>>> that introduces the new JGroups.
> >>>>>>
> >>>>>> The packages are currently a mess of com.gemstone.*, com.vmware.*,
> >>>>>> joptsimple.*, org.json.* (would we change all four or just the
> >>>>>> gemstone/vmware packages?).
> >>>>>>
> >>>>>> I'm probably biting off more than I should, but I'd be willing head
> >>> up
> >>>>> the
> >>>>>> package renaming effort.
> >>>>>>
> >>>>>> I think maintaining backwards compatibility (rolling upgrades
> >>> included)
> >>>>> for
> >>>>>> releases following Geode 1.0 is a definite requirement. I'd like to
> >>> see
> >>>>> the
> >>>>>> other discussion thread about defining the Geode protocol(s)
> converge
> >>>>> with
> >>>>>> this thread. Officially defining the communication protocols
> >>> (cluster,
> >>>>>> client/server, etc) would ideally happen in conjunction with 1.0 so
> >>>> that
> >>>>>> it's concrete and less ambiguous for 2.0 and later releases.
> >>>>>>
> >>>>>> -Kirk
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <ds...@pivotal.io>
> >>> wrote:
> >>>>>>
> >>>>>>> We've been releasing milestones of 1.0, but at some point we
> >>> actually
> >>>>>> have
> >>>>>>> to release a real geode 1.0 :)
> >>>>>>>
> >>>>>>> What is keeping us from releasing geode 1.0 at this point? Just the
> >>>>>> issues
> >>>>>>> currently marked with Fix Version M3? I think we should nail down
> >>> the
> >>>>>> scope
> >>>>>>> of 1.0 and track our progress to the 1.0 release.
> >>>>>>>
> >>>>>>> From the apache process perspective, I don't think 1.0 is any
> >>>> different
> >>>>>>> from the milestone releases we've done so far. The only difference
> >>>> with
> >>>>>> 1.0
> >>>>>>> is what it means to the geode community.
> >>>>>>>
> >>>>>>> Gemfire maintained backwards compatibility with previous releases
> >>> for
> >>>>>>> persistent files, client/server, WAN, and P2P messaging. I think
> >>> once
> >>>>> we
> >>>>>>> release 1.0 we should provide that same guarantee that the next
> >>> geode
> >>>>>>> release will be backwards compatible with 1.0.
> >>>>>>>
> >>>>>>> We do still have the package renaming (GEODE-37) on the horizon. My
> >>>>>>> suggestion is that in the interests of getting 1.0 out the door, at
> >>>>> this
> >>>>>>> point we should just release geode 1.0 with the old packages and
> >>>> rename
> >>>>>>> packages in geode 2.0.
> >>>>>>>
> >>>>>>> Thoughts?
> >>>>>>>
> >>>>>>> -Dan
> >>
> >>
> >>
> >> --
> >>
> >> ~/William
> >
>
--
~/William
Re: What will it take to release geode 1.0?
Posted by bd...@gmail.com.
Did Kirk's note about package renaming make the M3 scope? I think it would be great to start Geode's 1.0 on a consistent naming standard.
:)
Pro-Geode!!!
Brian -
Sent from my iPhone
> On May 3, 2016, at 6:09 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
> William,
>
> What do you think about including these in M3?
>
> GEODE-612 Update Jackson version since current version is not on Maven central
> GEODE-1028 Broken website link
> GEODE-1191 HDFS references
> GEODE-1133 SeparateClassloaderTestRunner
> GEODE-1260 Source distribution version info
>
> Anthony
>
>
>> On May 3, 2016, at 3:49 PM, William Markito <wm...@pivotal.io> wrote:
>>
>> Guys, restarting this thread to get a discussion going about M3, 1.0.0 and
>> next - As the release manager for M3 here is what I'd like to propose.
>>
>> Any feedback is welcome and let's also reuse this thread to talk a little
>> bit about roadmap as well ?
>>
>> # Current M3 Scope (
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
>> )
>>
>> GEODE-33
>> GEODE-823
>> GEODE-835
>> GEODE-919
>> GEODE-1146
>> GEODE-1168
>> GEODE-1203
>> GEODE-1259
>> GEODE-1278
>> GEODE-1293
>> GEODE-1316
>> GEODE-1256
>> GEODE-1267
>>
>> == Proposed scope & roadmap ==
>>
>> I'd like to breakdown the release a little bit and already start planning
>> the next releases.
>>
>> # Geode 1.0.0-incubating M3
>>
>> GEODE-1316 Update @since tags to include GemFire or Geode in the version
>> name
>> GEODE-1293 Align code and docs for modules
>> GEODE-1278 AbstractPeerTXRegionStub should throw
>> TransactionDataNodeHasDeparted when remote cache is closed
>> GEODE-1267 NOTICE file improvements
>> GEODE-1256 Geode website - Unapproved licenses
>> GEODE-1203 gfsh connect --use-http reports a ClassNotFoundException
>> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, asc.sha1)
>> GEODE-835 Replace joptsimple source with a binary dependency
>> GEODE-823 RC Feedback: Fix build artifacts
>> GEODE-33-1 Create project examples
>>
>> # Geode 1.0.0-incubating
>>
>> GEODE-33-2 Create project examples
>> GEODE-1331 gfsh.bat on Windows is incorrect
>> GEODE-1168 geode-dependencies manifest is missing jars that are present in
>> the lib directory
>> GEODE-629 Replace use of org.json with Jackson JSON library
>> GEODE-607 the offheap package needs better unit test coverage
>> GEODE-136 Fix possible NullPointerException in Gfsh's 'list regions'
>> command's GetRegionsFunction.
>>
>> # Geode 1.X.0-incubating
>>
>> GEODE-17 Provide Integrated Security
>> GEODE-11 Lucene Integration
>> GEODE-33-3 Create project examples
>>
>> # Geode 2.0.0-incubating
>>
>> GEODE-72 Remove deprecated APIs from Geode
>> GEODE-37 Package renaming
>> ---------------------------
>>
>> Comments:
>>
>> GEODE-33 would be broken into 3 different tasks, where on M3 we would start
>> with the example structure and a few examples, and incrementally add more
>> examples in the next releases.
>>
>> GEODE-37 is the package rename which due to the huge effort in testing and
>> with the goal to complete the removal of deprecated API's (GEODE-72 and
>> it's sub-tasks) would be pushed to 2.0. This would also allow faster
>> releases in 1.0.0 series.
>>
>>
>> Thanks,
>>
>> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <ni...@gmail.com>
>> wrote:
>>
>>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io> wrote:
>>>>
>>>> I'm not sure if the docs are a prerequisite for graduation. I don't think
>>>> there are specific requirements about the level of documentation for
>>>> graduation, just about community involvement - which docs could help
>>>> encourage :)
>>>
>>> I think this is a grey area with the user docs being on a vendor site.
>>> Theres a requirement that "every podling site sources should be maintained
>>> in the podling's site SVN or git directory"[1]. Clearly geode meets this to
>>> the letter of the law and I've seen other projects websites point to
>>> external resources that are useful. Since theres a plan to donate them at
>>> some point, my guess is it wouldn't be an issue.
>>>
>>> [1] http://incubator.apache.org/guides/sites.html
>>>
>>>
>>>
>>>> In any case we don't need to graduate or even be graduation ready to
>>>> release 1.0. The version number 1.0 has no special meaning to the ASF as
>>>> far as I can tell. But I think having regular releases and having an
>>>> official non-milestone release will help us grow the community.
>>>
>>> A release without a milestone/alpha/beta qualifier is going to indicate
>>> this community thinks its ready for serious use - so while you're right
>>> from a ASF perspective, it will have a special meaning for the wider geode
>>> community. And while keeping the existing package names makes the
>>> transition easier for existing gemfire users, a package rename in a later
>>> version will add pain to the new vast(hopefully!) user base for geode. So I
>>> would say do it now rather than later.
>>>
>>> However, if you're going to change the package name, then its also a good
>>> time to remove any deprecated features and correct/change any API's that
>>> you're not 100% happy with - which may be alot more work than just changing
>>> the package name.
>>>
>>> Niall
>>>
>>>
>>>>
>>>> This page has some information on what's required for graduation:
>>> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
>>>>
>>>> -Dan
>>>>
>>>>
>>>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <db...@pivotal.io> wrote:
>>>>>
>>>>> We plan at some point to donate the docs so they'll be incorporated
>>> into
>>>>> the repo. Is this a prerequisite to graduating from incubation?
>>>>>
>>>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <kl...@pivotal.io> wrote:
>>>>>>
>>>>>> The package renaming would most likely break some backwards
>>>> compatibility
>>>>>> between 1.0 and 2.0. I'd prefer to see the packages get renamed
>>> before
>>>>> 1.0
>>>>>> so we can change the packages of Message classes, etc in the same
>>>> release
>>>>>> that introduces the new JGroups.
>>>>>>
>>>>>> The packages are currently a mess of com.gemstone.*, com.vmware.*,
>>>>>> joptsimple.*, org.json.* (would we change all four or just the
>>>>>> gemstone/vmware packages?).
>>>>>>
>>>>>> I'm probably biting off more than I should, but I'd be willing head
>>> up
>>>>> the
>>>>>> package renaming effort.
>>>>>>
>>>>>> I think maintaining backwards compatibility (rolling upgrades
>>> included)
>>>>> for
>>>>>> releases following Geode 1.0 is a definite requirement. I'd like to
>>> see
>>>>> the
>>>>>> other discussion thread about defining the Geode protocol(s) converge
>>>>> with
>>>>>> this thread. Officially defining the communication protocols
>>> (cluster,
>>>>>> client/server, etc) would ideally happen in conjunction with 1.0 so
>>>> that
>>>>>> it's concrete and less ambiguous for 2.0 and later releases.
>>>>>>
>>>>>> -Kirk
>>>>>>
>>>>>>
>>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <ds...@pivotal.io>
>>> wrote:
>>>>>>
>>>>>>> We've been releasing milestones of 1.0, but at some point we
>>> actually
>>>>>> have
>>>>>>> to release a real geode 1.0 :)
>>>>>>>
>>>>>>> What is keeping us from releasing geode 1.0 at this point? Just the
>>>>>> issues
>>>>>>> currently marked with Fix Version M3? I think we should nail down
>>> the
>>>>>> scope
>>>>>>> of 1.0 and track our progress to the 1.0 release.
>>>>>>>
>>>>>>> From the apache process perspective, I don't think 1.0 is any
>>>> different
>>>>>>> from the milestone releases we've done so far. The only difference
>>>> with
>>>>>> 1.0
>>>>>>> is what it means to the geode community.
>>>>>>>
>>>>>>> Gemfire maintained backwards compatibility with previous releases
>>> for
>>>>>>> persistent files, client/server, WAN, and P2P messaging. I think
>>> once
>>>>> we
>>>>>>> release 1.0 we should provide that same guarantee that the next
>>> geode
>>>>>>> release will be backwards compatible with 1.0.
>>>>>>>
>>>>>>> We do still have the package renaming (GEODE-37) on the horizon. My
>>>>>>> suggestion is that in the interests of getting 1.0 out the door, at
>>>>> this
>>>>>>> point we should just release geode 1.0 with the old packages and
>>>> rename
>>>>>>> packages in geode 2.0.
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> -Dan
>>
>>
>>
>> --
>>
>> ~/William
>
Re: What will it take to release geode 1.0?
Posted by Anthony Baker <ab...@pivotal.io>.
William,
What do you think about including these in M3?
GEODE-612 Update Jackson version since current version is not on Maven central
GEODE-1028 Broken website link
GEODE-1191 HDFS references
GEODE-1133 SeparateClassloaderTestRunner
GEODE-1260 Source distribution version info
Anthony
> On May 3, 2016, at 3:49 PM, William Markito <wm...@pivotal.io> wrote:
>
> Guys, restarting this thread to get a discussion going about M3, 1.0.0 and
> next - As the release manager for M3 here is what I'd like to propose.
>
> Any feedback is welcome and let's also reuse this thread to talk a little
> bit about roadmap as well ?
>
> # Current M3 Scope (
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
> )
>
> GEODE-33
> GEODE-823
> GEODE-835
> GEODE-919
> GEODE-1146
> GEODE-1168
> GEODE-1203
> GEODE-1259
> GEODE-1278
> GEODE-1293
> GEODE-1316
> GEODE-1256
> GEODE-1267
>
> == Proposed scope & roadmap ==
>
> I'd like to breakdown the release a little bit and already start planning
> the next releases.
>
> # Geode 1.0.0-incubating M3
>
> GEODE-1316 Update @since tags to include GemFire or Geode in the version
> name
> GEODE-1293 Align code and docs for modules
> GEODE-1278 AbstractPeerTXRegionStub should throw
> TransactionDataNodeHasDeparted when remote cache is closed
> GEODE-1267 NOTICE file improvements
> GEODE-1256 Geode website - Unapproved licenses
> GEODE-1203 gfsh connect --use-http reports a ClassNotFoundException
> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, asc.sha1)
> GEODE-835 Replace joptsimple source with a binary dependency
> GEODE-823 RC Feedback: Fix build artifacts
> GEODE-33-1 Create project examples
>
> # Geode 1.0.0-incubating
>
> GEODE-33-2 Create project examples
> GEODE-1331 gfsh.bat on Windows is incorrect
> GEODE-1168 geode-dependencies manifest is missing jars that are present in
> the lib directory
> GEODE-629 Replace use of org.json with Jackson JSON library
> GEODE-607 the offheap package needs better unit test coverage
> GEODE-136 Fix possible NullPointerException in Gfsh's 'list regions'
> command's GetRegionsFunction.
>
> # Geode 1.X.0-incubating
>
> GEODE-17 Provide Integrated Security
> GEODE-11 Lucene Integration
> GEODE-33-3 Create project examples
>
> # Geode 2.0.0-incubating
>
> GEODE-72 Remove deprecated APIs from Geode
> GEODE-37 Package renaming
> ---------------------------
>
> Comments:
>
> GEODE-33 would be broken into 3 different tasks, where on M3 we would start
> with the example structure and a few examples, and incrementally add more
> examples in the next releases.
>
> GEODE-37 is the package rename which due to the huge effort in testing and
> with the goal to complete the removal of deprecated API's (GEODE-72 and
> it's sub-tasks) would be pushed to 2.0. This would also allow faster
> releases in 1.0.0 series.
>
>
> Thanks,
>
> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <ni...@gmail.com>
> wrote:
>
>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io> wrote:
>>
>>> I'm not sure if the docs are a prerequisite for graduation. I don't think
>>> there are specific requirements about the level of documentation for
>>> graduation, just about community involvement - which docs could help
>>> encourage :)
>>>
>>
>> I think this is a grey area with the user docs being on a vendor site.
>> Theres a requirement that "every podling site sources should be maintained
>> in the podling's site SVN or git directory"[1]. Clearly geode meets this to
>> the letter of the law and I've seen other projects websites point to
>> external resources that are useful. Since theres a plan to donate them at
>> some point, my guess is it wouldn't be an issue.
>>
>> [1] http://incubator.apache.org/guides/sites.html
>>
>>
>>
>>> In any case we don't need to graduate or even be graduation ready to
>>> release 1.0. The version number 1.0 has no special meaning to the ASF as
>>> far as I can tell. But I think having regular releases and having an
>>> official non-milestone release will help us grow the community.
>>>
>>
>> A release without a milestone/alpha/beta qualifier is going to indicate
>> this community thinks its ready for serious use - so while you're right
>> from a ASF perspective, it will have a special meaning for the wider geode
>> community. And while keeping the existing package names makes the
>> transition easier for existing gemfire users, a package rename in a later
>> version will add pain to the new vast(hopefully!) user base for geode. So I
>> would say do it now rather than later.
>>
>> However, if you're going to change the package name, then its also a good
>> time to remove any deprecated features and correct/change any API's that
>> you're not 100% happy with - which may be alot more work than just changing
>> the package name.
>>
>> Niall
>>
>>
>>>
>>> This page has some information on what's required for graduation:
>>>
>>>
>> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
>>>
>>> -Dan
>>>
>>>
>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <db...@pivotal.io> wrote:
>>>
>>>> We plan at some point to donate the docs so they'll be incorporated
>> into
>>>> the repo. Is this a prerequisite to graduating from incubation?
>>>>
>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <kl...@pivotal.io> wrote:
>>>>
>>>>> The package renaming would most likely break some backwards
>>> compatibility
>>>>> between 1.0 and 2.0. I'd prefer to see the packages get renamed
>> before
>>>> 1.0
>>>>> so we can change the packages of Message classes, etc in the same
>>> release
>>>>> that introduces the new JGroups.
>>>>>
>>>>> The packages are currently a mess of com.gemstone.*, com.vmware.*,
>>>>> joptsimple.*, org.json.* (would we change all four or just the
>>>>> gemstone/vmware packages?).
>>>>>
>>>>> I'm probably biting off more than I should, but I'd be willing head
>> up
>>>> the
>>>>> package renaming effort.
>>>>>
>>>>> I think maintaining backwards compatibility (rolling upgrades
>> included)
>>>> for
>>>>> releases following Geode 1.0 is a definite requirement. I'd like to
>> see
>>>> the
>>>>> other discussion thread about defining the Geode protocol(s) converge
>>>> with
>>>>> this thread. Officially defining the communication protocols
>> (cluster,
>>>>> client/server, etc) would ideally happen in conjunction with 1.0 so
>>> that
>>>>> it's concrete and less ambiguous for 2.0 and later releases.
>>>>>
>>>>> -Kirk
>>>>>
>>>>>
>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <ds...@pivotal.io>
>> wrote:
>>>>>
>>>>>> We've been releasing milestones of 1.0, but at some point we
>> actually
>>>>> have
>>>>>> to release a real geode 1.0 :)
>>>>>>
>>>>>> What is keeping us from releasing geode 1.0 at this point? Just the
>>>>> issues
>>>>>> currently marked with Fix Version M3? I think we should nail down
>> the
>>>>> scope
>>>>>> of 1.0 and track our progress to the 1.0 release.
>>>>>>
>>>>>> From the apache process perspective, I don't think 1.0 is any
>>> different
>>>>>> from the milestone releases we've done so far. The only difference
>>> with
>>>>> 1.0
>>>>>> is what it means to the geode community.
>>>>>>
>>>>>> Gemfire maintained backwards compatibility with previous releases
>> for
>>>>>> persistent files, client/server, WAN, and P2P messaging. I think
>> once
>>>> we
>>>>>> release 1.0 we should provide that same guarantee that the next
>> geode
>>>>>> release will be backwards compatible with 1.0.
>>>>>>
>>>>>> We do still have the package renaming (GEODE-37) on the horizon. My
>>>>>> suggestion is that in the interests of getting 1.0 out the door, at
>>>> this
>>>>>> point we should just release geode 1.0 with the old packages and
>>> rename
>>>>>> packages in geode 2.0.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
>
> --
>
> ~/William
Re: What will it take to release geode 1.0?
Posted by William Markito <wm...@pivotal.io>.
Guys, restarting this thread to get a discussion going about M3, 1.0.0 and
next - As the release manager for M3 here is what I'd like to propose.
Any feedback is welcome and let's also reuse this thread to talk a little
bit about roadmap as well ?
# Current M3 Scope (
https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
)
GEODE-33
GEODE-823
GEODE-835
GEODE-919
GEODE-1146
GEODE-1168
GEODE-1203
GEODE-1259
GEODE-1278
GEODE-1293
GEODE-1316
GEODE-1256
GEODE-1267
== Proposed scope & roadmap ==
I'd like to breakdown the release a little bit and already start planning
the next releases.
# Geode 1.0.0-incubating M3
GEODE-1316 Update @since tags to include GemFire or Geode in the version
name
GEODE-1293 Align code and docs for modules
GEODE-1278 AbstractPeerTXRegionStub should throw
TransactionDataNodeHasDeparted when remote cache is closed
GEODE-1267 NOTICE file improvements
GEODE-1256 Geode website - Unapproved licenses
GEODE-1203 gfsh connect --use-http reports a ClassNotFoundException
GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, asc.sha1)
GEODE-835 Replace joptsimple source with a binary dependency
GEODE-823 RC Feedback: Fix build artifacts
GEODE-33-1 Create project examples
# Geode 1.0.0-incubating
GEODE-33-2 Create project examples
GEODE-1331 gfsh.bat on Windows is incorrect
GEODE-1168 geode-dependencies manifest is missing jars that are present in
the lib directory
GEODE-629 Replace use of org.json with Jackson JSON library
GEODE-607 the offheap package needs better unit test coverage
GEODE-136 Fix possible NullPointerException in Gfsh's 'list regions'
command's GetRegionsFunction.
# Geode 1.X.0-incubating
GEODE-17 Provide Integrated Security
GEODE-11 Lucene Integration
GEODE-33-3 Create project examples
# Geode 2.0.0-incubating
GEODE-72 Remove deprecated APIs from Geode
GEODE-37 Package renaming
---------------------------
Comments:
GEODE-33 would be broken into 3 different tasks, where on M3 we would start
with the example structure and a few examples, and incrementally add more
examples in the next releases.
GEODE-37 is the package rename which due to the huge effort in testing and
with the goal to complete the removal of deprecated API's (GEODE-72 and
it's sub-tasks) would be pushed to 2.0. This would also allow faster
releases in 1.0.0 series.
Thanks,
On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <ni...@gmail.com>
wrote:
> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <ds...@pivotal.io> wrote:
>
> > I'm not sure if the docs are a prerequisite for graduation. I don't think
> > there are specific requirements about the level of documentation for
> > graduation, just about community involvement - which docs could help
> > encourage :)
> >
>
> I think this is a grey area with the user docs being on a vendor site.
> Theres a requirement that "every podling site sources should be maintained
> in the podling's site SVN or git directory"[1]. Clearly geode meets this to
> the letter of the law and I've seen other projects websites point to
> external resources that are useful. Since theres a plan to donate them at
> some point, my guess is it wouldn't be an issue.
>
> [1] http://incubator.apache.org/guides/sites.html
>
>
>
> > In any case we don't need to graduate or even be graduation ready to
> > release 1.0. The version number 1.0 has no special meaning to the ASF as
> > far as I can tell. But I think having regular releases and having an
> > official non-milestone release will help us grow the community.
> >
>
> A release without a milestone/alpha/beta qualifier is going to indicate
> this community thinks its ready for serious use - so while you're right
> from a ASF perspective, it will have a special meaning for the wider geode
> community. And while keeping the existing package names makes the
> transition easier for existing gemfire users, a package rename in a later
> version will add pain to the new vast(hopefully!) user base for geode. So I
> would say do it now rather than later.
>
> However, if you're going to change the package name, then its also a good
> time to remove any deprecated features and correct/change any API's that
> you're not 100% happy with - which may be alot more work than just changing
> the package name.
>
> Niall
>
>
> >
> > This page has some information on what's required for graduation:
> >
> >
> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
> >
> > -Dan
> >
> >
> > On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <db...@pivotal.io> wrote:
> >
> > > We plan at some point to donate the docs so they'll be incorporated
> into
> > > the repo. Is this a prerequisite to graduating from incubation?
> > >
> > > On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <kl...@pivotal.io> wrote:
> > >
> > > > The package renaming would most likely break some backwards
> > compatibility
> > > > between 1.0 and 2.0. I'd prefer to see the packages get renamed
> before
> > > 1.0
> > > > so we can change the packages of Message classes, etc in the same
> > release
> > > > that introduces the new JGroups.
> > > >
> > > > The packages are currently a mess of com.gemstone.*, com.vmware.*,
> > > > joptsimple.*, org.json.* (would we change all four or just the
> > > > gemstone/vmware packages?).
> > > >
> > > > I'm probably biting off more than I should, but I'd be willing head
> up
> > > the
> > > > package renaming effort.
> > > >
> > > > I think maintaining backwards compatibility (rolling upgrades
> included)
> > > for
> > > > releases following Geode 1.0 is a definite requirement. I'd like to
> see
> > > the
> > > > other discussion thread about defining the Geode protocol(s) converge
> > > with
> > > > this thread. Officially defining the communication protocols
> (cluster,
> > > > client/server, etc) would ideally happen in conjunction with 1.0 so
> > that
> > > > it's concrete and less ambiguous for 2.0 and later releases.
> > > >
> > > > -Kirk
> > > >
> > > >
> > > > On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <ds...@pivotal.io>
> wrote:
> > > >
> > > > > We've been releasing milestones of 1.0, but at some point we
> actually
> > > > have
> > > > > to release a real geode 1.0 :)
> > > > >
> > > > > What is keeping us from releasing geode 1.0 at this point? Just the
> > > > issues
> > > > > currently marked with Fix Version M3? I think we should nail down
> the
> > > > scope
> > > > > of 1.0 and track our progress to the 1.0 release.
> > > > >
> > > > > From the apache process perspective, I don't think 1.0 is any
> > different
> > > > > from the milestone releases we've done so far. The only difference
> > with
> > > > 1.0
> > > > > is what it means to the geode community.
> > > > >
> > > > > Gemfire maintained backwards compatibility with previous releases
> for
> > > > > persistent files, client/server, WAN, and P2P messaging. I think
> once
> > > we
> > > > > release 1.0 we should provide that same guarantee that the next
> geode
> > > > > release will be backwards compatible with 1.0.
> > > > >
> > > > > We do still have the package renaming (GEODE-37) on the horizon. My
> > > > > suggestion is that in the interests of getting 1.0 out the door, at
> > > this
> > > > > point we should just release geode 1.0 with the old packages and
> > rename
> > > > > packages in geode 2.0.
> > > > >
> > > > > Thoughts?
> > > > >
> > > > > -Dan
> > > > >
> > > >
> > >
> >
>
--
~/William