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

[Yves Jacolin]

On Thursday, July 28, 2016 9:01:16 Richard Duivenvoorde wrote:
> On 28-07-16 01:33, DelazJ wrote:
> >     talk about 2.16? :) Let's focus to 2.18/3.0.
> > 
> > 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?
> > 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.
> > 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.
> > 
> >     Spliting ticket in two milestone needs some work for the next 3-4
> >     monthes, I
> > 
> > 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?
> > 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.
> 
> Hi, well, writing(!) documentation for features which landed in 2.16 and
> 2.18 is never wrong :-) As they will be ported to 3.0 too, so will be
> documented then for the 3.0 (or 3.2) LTR version of the docs ...
> 
> But IF we want to keep if possible to release a 2.1x version (I
> hope/think we should make that a LTR too then) we cannot add stuff which
> only lands in 3.0 branch (which hopefully will be the case too)...
> But that is off course OK: we have enough to document from 2.16 and 2.18
> (master_2) branches... if all those 2.16 and 2.18 issues (IF you label
> them such) are closed, and there is nothing to do, we can decide what to
> do next...?
> 
> Also on my wishlist (for 3.0) is to restructure docs, by (maybe) making
> all text markdown (making it easier to write), and only the index pages
> rst (because then we can make index pages, toc's etc ...)
> We would loose the ability to do cross reference in texts, but... maybe
> if we keep the docs as flat as possible, meaning just two layers dep:
> - index (rst)
> -    directory
> -      text (markdown)
> And do the text more like 'info cards' (having deep links to parts of
> it), we can use those in QGIS itself too.
> All this to make it possible/easier to show the images in github and
> make it easier for people to write/fix/update documentation...
> 
> Ok with this?
> 
> Regards,
> 
Richard, Harrissou,

Thanks both. Now I understand better what meant Harrissou.

Brainstorming a little bit, we may keep working on 2.16 from which we can make 
a 2.18 branch? And cherry pick some commit from master to this branch.

As soon as 2.18 is released, we can make the big bang to the master for the 
3.0 release (ie change structure, etc). That's way we can still work on 3.0 
feature in master and have a 2.18 release.

Harrissou, would you mind to take care of the cherry pick to 2.18 branch? 
Writer should contribute to master with a label '2.18' or so to let the "2.18 
manager" know which commit to cherry-pick to the PR.

Though?

Y.