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
