[openlp-dev] Release Schedule

[Olli Suutari]

Perhaps we could start doing nightly builds on monthly basis?


This way we could keep releasing new features and fixes for testing, which
could speed
up the release process and help in finding bugs via the community
volunteers.


This could also lead in more stable release candidates,
normal users tend to freak out when there’s a bunch of
unexpected bugs in the release.


Of course, these builds should be clearly labelled as unstable.

Cheers,

Olli Suutari,
Azaziah


On 3 December 2016 at 23:12, Tomas Groth <second at tgc.dk> wrote:

> Hi,
>
> 2016-12-03 16:36 GMT+01:00 Raoul Snyman <raoul at snyman.info>:
>
>> The time between major releases is too long.  I fixed 6 major video bugs a
>>> year ago and with the Beta and RC releases they will not be out till
>>> Easter.  This is not a complaint but a fact of life, when we need to
>>> release good bug-free software.
>>>
>>
>> Very true. This has been the most chaotic year of my life, to be honest.
>>
>
> Aye, limited resources and time is an issue, but such is life.
>
>
>>
>>
>> OpenLP is getting more stable and the bug re-writes should be getting less
>>> but we need to be able to continue to release so here is a proposal.
>>>
>>>
>>>    1. Release 2.6 with current functionality (maybe we fix up some of the
>>>    small improvements) and target it for Easter
>>>    2. Add web updates into 2.8
>>>    3. Target renderer to 2.8 or 3.0 depending on how long it takes to
>>> make
>>>    stable
>>>
>>
>> Yes, I think this is a good idea. My only proviso is this: WebKit is
>> going the way of the dodo, WebEngine is supposed to be the new cool, but
>> between the distros and the macOS and Windows builds, I'm not sure how much
>> longer we can use WebKit for.
>>
>
> It would be really great to do the switch from QtWebkit to QtWebEngine
> before 2.6, but I guess it isn't realistic to get it done unless someone
> suddenly gets a lot of time on his hands. But since QtWebEngine still
> hasen't made it into debian and ubuntu yet, maybe that is ok for now -
> though we could probably use snap-packages as a workaround.
> If we stay on QtWebkit we are also stuck on python 3.4 and PyQt 5.5 on
> windows (since later PyQt versions for win doesn't contain QtWebkit). But
> that could actually be good, since PyInstaller currently has an issue with
> Python 3.5 that causes apps built on win10 not to work on older windows
> versions (https://github.com/pyinstaller/pyinstaller/issues/1566).
> So maybe it's a good idea to stick with QtWebkit for one more release.
>
>
>>
>> Maybe change the naming OpenLP 2016 and OpenLP 2017 targetted for the 1st
>>> quarter each year would be a way forward. with bug fixes targetted at
>>> Sept
>>> and Dec unless there are major showstoppers like HTML changes at
>>> SongSelect
>>> or Bible Gateway.
>>>
>>
>> Urgh, personally I hate year numbers instead of version numbers. But
>> targetting a release for the first quarter of each year sounds like a good
>> idea.
>>
>> I do think we've gotten the release procedure down fairly well
>> (especially when I follow the instructions I wrote for myself on the wiki),
>> so once we have a regular release cycle for new versions, maybe we can
>> speed it up to 2 per year.
>>
>> I would also like to stick to the current numbering scheme, but targeting
> a feature release for each spring sounds good to me.
>
> Best regards,
> Tomas
>
> _______________________________________________
> openlp-dev mailing list
> openlp-dev at openlp.io
> https://lists.openlp.io/mailman/listinfo/openlp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openlp.io/pipermail/openlp-dev/attachments/20161204/a81ac191/attachment.html>