Ahh, my misunderstanding...I thought '1.0' was synonymous with 'post-incubation'. We're hoping to convert our docs from DITA to Markdown before contributing to ASF, still in the early stages of that conversion. We'll keep plugging away and keep our eye on the software releases.
On Fri, Apr 29, 2016 at 2: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 :) > > 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. > > 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 > > > > > > > > > >
