Hello, Yea, that works for me. Just to be certain, both users and providers will have "Gremlin Process" and "Gremlin Structure" stuff to deal with. Perhaps those are in the … you have.
Thanks, Marko. http://markorodriguez.com On Nov 5, 2015, at 4:41 AM, Stephen Mallette <[email protected]> wrote: > The more I look at this, the more I think the answer is to drop the > "Important Changes" sections (it's not developing the way I thought that > would), and simply migrate those bullets to the existing appropriate > sections in the document if they are not already represented. That would > leave the upgrade docs with this kind of structure: > > TinkerPop 3.1.0 > Upgrading for Users > Gremlin Structure > Transaction.close() Default Behavior > Hadoop-Gremlin Updates > Gremlin Process > ... > Gremlin Server > ... > Upgrading for Providers > Graph System Providers > Decomposition of AbstractTransaction > Transaction.close() Default Behavior > ... > Graph Driver Providers > .... > > How's that looking? > > > On Tue, Nov 3, 2015 at 3:06 PM, Stephen Mallette <[email protected]> > wrote: > >> Agreed - it could be better. We should get a better pattern sorted for >> 3.1.0. Here was my thinking for where I started with the upgrade docs: >> >> 1. I didn't want a endless bullet list of stuff because that's just >> changelog. >> 2 We often need to explain in greater detail than a single sentence or >> two what upgrading entails - especially for providers who have to deal with >> changes that break their stuff. >> 3. I think it's worth having organization that pertains to different types >> of TinkerPop users (i.e. end user vs. provider). >> >> now that we have some actual releases going back to 3.0.1 and 3.0.2 we can >> see the kinds of content we had and re-arrange as necessary. i'll keep the >> hangout thing in mind as a thing we do for release week. >> >> On Mon, Nov 2, 2015 at 10:57 AM, Marko Rodriguez <[email protected]> >> wrote: >> >>> Hi, >>> >>> I think the upgrade docs are poorly organized. I think once we do our >>> code freeze, we should have a Google Hangout and discuss the best way to >>> structure it. I was about to say: "we should do it like this…" but then >>> realized situations that make the categorization I was going to propose >>> awkward… >>> >>> In short, I think we need to come up with a consistent pattern we will >>> use into the future that easily encapsulates all the types of changes we >>> will need to make users/providers aware of. >>> >>> …, >>> Marko. >>> >>> http://markorodriguez.com >>> >>> >>
