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