<div dir="ltr">Hi Yves,<br><div class="gmail_extra"><br><div class="gmail_quote">2016-07-27 15:38 GMT+02:00 Yves Jacolin <span dir="ltr"><<a target="_blank" href="mailto:yjacolin@free.fr">yjacolin@free.fr</a>></span>:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">On Wednesday, July 27, 2016 12:21:18 DelazJ wrote:<br>
> Yves, with the API break due to 3.x releases, there are now two branches in<br>
> qgis/QGIS repository:<br>
> - master for 3.0 commits<br>
> - and master_2 for 2.18 commits (where there's no API break)<br>
> As already mentioned earlier in this thread, all fixes or new features in<br>
> master_2 are also present in master.<br>
</span>Yes, I get it, no problem.<br>
<span class="gmail-"><br>
> Then, with the automatic creation of issues in QGIS-Documentation repo, we<br>
> can get features from master as well as master_2 (examples in my latest<br>
> message). By default, they are labeled 3.0. All we need to do is (re)label<br>
> some of them according to the branch they belong to in QGIS repo (master<br>
> --> 3.0, master_2 --> 2.18).<br>
> For the doc writing, I think that as usual, we'll be tackling 2.16 issues<br>
> for the moment (as it's the released version) in doc master branch. One<br>
> release at a moment. The other releases are not concerned for the moment.<br>
</span>So why do we need to split the ticket of the doc in two milestone? The topic<br>
of the thread is "Managing a future 2.18 or 3.0 documentation", so why do we<br>
talk about 2.16? :) Let's focus to 2.18/3.0.<br>
<br></blockquote><div>I mentioned 2.16 just because it's what we are working on now. And the purpose of this discussion is : And then? What do we do after 2.16 issues are all fixed?<br>And actually, as Andreas said earlier, when 2.18 is released and if it's the last 2.x version, then I think it's more coherent to have a 2.18 doc than a 2.16 doc.<br>If there is a
 need of a 2.x doc after 2.14 LTR, I think it should be for the last release in 2.x. That means being able to identify 2.x commits from 3.x ones.<br><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Spliting ticket in two milestone needs some work for the next 3-4 monthes, I<br>
am not against that you managed it ;) but I am wondering what is the final<br>
purpose of this work if at the end, we are only managing 3.0 release for the<br>
documentation.<br>
<br></blockquote><div>If we do not publish another 2.x doc, sure I'd have wasted my time (not so much though). And afaics, it'd be the only harm. But what if 3.0 takes too long and that 2.16 issues are meanwhile all documented?<br>Most of 2.18 features are likely commited in 3.0 meaning that documenting those features is not a waste of time. All is done in a single master (testing) branch so that work will benefit to a 3.x documentation.<br><br></div><div>Regards,<br></div><div>Harrissou<br><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
I just want to understand your point of view.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Y.<br>
</font></span></blockquote></div><br></div></div>