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