[Qgis-developer] Managing a future 2.18 or 3.0 documentation?

[Yves Jacolin]

On Wednesday, July 27, 2016 12:21:18 DelazJ wrote:
> Yves, with the API break due to 3.x releases, there are now two branches in
> qgis/QGIS repository:
> - master for 3.0 commits
> - and master_2 for 2.18 commits (where there's no API break)
> As already mentioned earlier in this thread, all fixes or new features in
> master_2 are also present in master.
Yes, I get it, no problem.

> Then, with the automatic creation of issues in QGIS-Documentation repo, we
> can get features from master as well as master_2 (examples in my latest
> message). By default, they are labeled 3.0. All we need to do is (re)label
> some of them according to the branch they belong to in QGIS repo (master
> --> 3.0, master_2 --> 2.18).
> For the doc writing, I think that as usual, we'll be tackling 2.16 issues
> for the moment (as it's the released version) in doc master branch. One
> release at a moment. The other releases are not concerned for the moment.
So why do we need to split the ticket of the doc in two milestone? The topic 
of the thread is "Managing a future 2.18 or 3.0 documentation", so why do we 
talk about 2.16? :) Let's focus to 2.18/3.0.

Spliting ticket in two milestone needs some work for the next 3-4 monthes, I 
am not against that you managed it ;) but I am wondering what is the final 
purpose of this work if at the end, we are only managing 3.0 release for the 
documentation.

I just want to understand your point of view.

Y.