Hi, Thanks for your comments Richard, I'll be doing it by hand for the moment, meaning that I'll create a 2.18 milestone and put issues from master_2 inside (often duplicated in 3.0, such as https://github.com/qgis/QGIS-Documentation/issues/1208 vs https://github.com/qgis/QGIS-Documentation/issues/1207; i'll then remove the copy from 3.0 milestone)
Do you agree with this process? Even if we do not know now if a 2.18 doc will be released, at least we'd have kept needed elements to write it if decision is made (will require more writers involved). Harrissou 2016-07-20 23:17 GMT+02:00 Richard Duivenvoorde <rdmaili...@duif.net>: > On 20-07-16 09:29, Yves Jacolin wrote: > > Matthias, Harrissou, > > > > On Wednesday, July 20, 2016 9:12:17 Matthias Kuhn wrote: > >> Hi Harrissou > >> > >> On 07/20/2016 08:47 AM, DelazJ wrote: > >> [..] > >> > >>> So questions: > >>> - Will we have a 2.18 (if ever) documentation? > >> > >> I think it would be good to plan 2.18 in general. Triggering the release > >> scripts should be trivial. Since some features end up in 2.18, I guess > >> it will happen. > >> Concerning docs and also pre-release fixing, I wonder if this effort > >> should be spent on the 3.0 migration instead? > > > > So, either we can know which feature is in 2.18 and which in 3.0 and we > can > > target the ticket (in the doc repository) in the two milestone and > without > > much work, or we can't. > > > > Anyway, as we are "still" working in the 2.16 release, I guess we can > aims to > > release it at the end of the year, not before. > > > > Next, we should focus on 3.0 to get the doc ready for QGIS 3.0, at the > > beginning of 2017. > > > > So +1 for your proposition. > > > >> [..] > >>> - Should the webhook set different milestions according to the branch > >>> used? > >> > >> Yes, master_2 => 2.18, master => 3.0. > > Are you sure? 2.18 milestone doesn't exist in the QGIS doc repository. > > > >> > >> Has there ever been a documentation released for 2.10 and 2.12? > >> If non-LTR get no documentation, there's probably not much point in > >> doing one for 2.18 I think? > >> People can still refer to the "testing" doc from master instead which > >> should match in many points (and where not, some notes can be included). > > Indeed, but this is more a consequence than a cause. In the mid term I > prefer > > that we add new feature in the doc in the same time that the ticket is > created > > and so get a documentation release for each QGIS release. > > We tried in history, but the doc (and doc release-) team could just not > cope with all the releases. So we more or less decided to only build (at > least translated) the docs for LTR versions. > > 2.16 is non-ltr and 2.18 is a special case.. so I would also be OK to > concentrate on a docs build for 3.0. So only pick features which will > be ported to 3.0 from 2.16 and 2.18 etcetc > > But we can off course try to follow... currently '[FEATURE]' is > automatically labeled as 3.0 milestone... > IF we want to distinguish between those, we either have to fix the script: > > https://github.com/qgis/QGIS-Sysadmin/blob/master/webhooks/github_feature_tracker.cgi > Or do it by hand... > > Regards, > > Richard > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer