Yes - exactly. I also think when possible that we should try to focus on "themes of change" rather than bullets when possible. Otherwise, we just have what feels like an "organized changelog". We can work on updating the upgrade docs next week during code freeze and bring them all in line with the new model. Anyone else have any thoughts on the matter?
On Thu, Nov 5, 2015 at 9:11 AM, Marko Rodriguez <[email protected]> wrote: > 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 > >>> > >>> > >> > >
