<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 02 Feb 2016, at 00:51, Nathan Woodrow <<a href="mailto:madmanwoo@gmail.com" class="">madmanwoo@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">HI all,<div class=""><br class=""></div><div class="">Just want to bring up <a href="https://www.loomio.org/d/5MCdPwoL/vote-to-approve-the-process-for-qgis-3-0" class="">https://www.loomio.org/d/5MCdPwoL/vote-to-approve-the-process-for-qgis-3-0</a></div><div class=""><br class=""></div><div class="">What are the main reasons for not just doing a cut after 2.16 and saying we are full time on 3.0 now? Are people worried about having a broken state (if you are running dev you should expect this anyway until feature freeze)</div><div class=""><br class=""></div><div class="">I feel parallel development, and on such a big migration, will burn out any resources we already have and 2.16 will be ignored anyway for most work.</div><div class=""><br class=""></div><div class="">For me just having to switch between LTR and non LTR for bug fixing is a pain let alone versions with different APIs, different release plans, different Python versions, etc</div><div class=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Thanks for your inputs Nathan. I am in the same camp as you. My preferred course of action is to:</div><div><br class=""></div><div>* release 2.14 LTR</div><div>* release 2.16 ‘transition release’</div><div>* release 3.x beta releases every 4 months based off master until we are ready (hopefully only one beta release)</div><div>* release 3.0 final</div><div>* release 3.2 LTR</div><div><br class=""></div><div>Juergen took issue with my suggestion in loomio based on why we would release stuff that is ‘not ready’. It is a fair point but I would like to propose that even with the shift to API breaking changes, we should not allow PRs to be merged if tests to do not pass. Master should always be kept in a runnable state. My motivation for labelling the 4 monthly releases as ‘beta’ (not ready) is that we do not present them as having the finalised API. So people can get early access to the next generation QGIS, releases keep coming every 4 months and plugin writers have something that can be broadly tested, while being aware that the API may change between the beta and final release.</div><div><br class=""></div><div>Anyway whether we go this route or another, it would be good to try to harmonise our thoughts - I don’t think it is great for the PSC to present a plan that only half of us agree on / believe in. One way to do this is to try to bullet out the individual high level requirements for a 3.0 release (e.g. shift to python 3, shift to PyQt5) in a table and have a column for each PSC member to agree or disagree with. That way we can isolate the specific contention points and focus on those. My feel is that most disagreement now lies with the branching strategy we use. As Andreas mentioned cynically, there has been a lot of flip flopping of positions so it is kind of hard to get a good idea of where the consensus lies. If anyone has a better idea of how to reach consensus, could you let us know what it is, otherwise I will set up the decision matrix that we can all put our agree/disagree notes into. OK?</div><div><br class=""></div><div>Regards</div><div><br class=""></div><div>Tim</div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Regards,</div><div class="">Nathan</div></div>
_______________________________________________<br class="">Qgis-psc mailing list<br class=""><a href="mailto:Qgis-psc@lists.osgeo.org" class="">Qgis-psc@lists.osgeo.org</a><br class="">http://lists.osgeo.org/mailman/listinfo/qgis-psc</div></blockquote></div><br class=""><div class="">
<span><img height="60" width="60" apple-inline="yes" id="2C6C523A-8C7A-4B31-BB97-225C9C230F88" apple-width="yes" apple-height="yes" src="cid:DDEF9B12-67C3-4498-BD7D-EC3563CC35A4" class=""></span><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class="Apple-interchange-newline"><br class=""></div><div class="">Tim Sutton</div><div class="">QGIS Project Steering Committee Member</div><div class=""><a href="mailto:tim@qgis.org" class="">tim@qgis.org</a></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>