@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, <bdunla...@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 <aba...@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 <wmark...@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.pember...@gmail.com> > >> wrote: > >> > >>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <dsm...@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 <dbar...@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 <dsm...@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
