[Qgis-psc] Moving to 3.0

[Tim Sutton]

Hi

> On 02 Feb 2016, at 00:51, Nathan Woodrow <madmanwoo at gmail.com> wrote:
> 
> HI all,
> 
> Just want to bring up https://www.loomio.org/d/5MCdPwoL/vote-to-approve-the-process-for-qgis-3-0 <https://www.loomio.org/d/5MCdPwoL/vote-to-approve-the-process-for-qgis-3-0>
> 
> 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)
> 
> 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.
> 
> 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
> 

Thanks for your inputs Nathan. I am in the same camp as you. My preferred course of action is to:

* release 2.14 LTR
* release 2.16 ‘transition release’
* release 3.x beta releases every 4 months based off master until we are ready (hopefully only one beta release)
* release 3.0 final
* release 3.2 LTR

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.

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?

Regards

Tim



> Regards,
> Nathan
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-psc




Tim Sutton
QGIS Project Steering Committee Member
tim at qgis.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160202/a59b8e52/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.tiff
Type: image/tiff
Size: 9882 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20160202/a59b8e52/attachment.tiff>