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
