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