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 <[email protected]> wrote: > Great discussion... > > On Tue, May 3, 2016 at 6:45 PM, Brian Dunlap <[email protected]> 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 <[email protected]> > > 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, <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > > > 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 < > > > > [email protected]> > > > > >> wrote: > > > > >> > > > > >>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <[email protected]> > > > > 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 < > [email protected] > > > > > > > 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 <[email protected] > > > > > > 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 < > [email protected]> > > > > >>> 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 >
