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
signature.asc
Description: Message signed with OpenPGP using GPGMail
