[Scummvm-devel] Proposed schedule for 2.0.0
Thierry Crozat
criezy at scummvm.org
Thu Nov 30 01:31:36 CET 2017
Hi all,
So to summarise our current release schedule is:
November 12: Release cycle starts, testing announced
November 22: List of bugs published. Trunk is frozen
November 29: branch, trunk unfrozen, porters contacted
December 8, Fri: tagging, tarballs uploaded, porters start submitting their builds
December 17: Release
I have now created branch-2-0 as per this schedule, and this means that master is now unfrozen.
Porters, please make sure that your ports are in working order. We have just 10 days left until tagging for the release.
Thierry
> On 26 Nov 2017, at 02:05, Thierry Crozat <criezy at scummvm.org> wrote:
>
> As suggested by Colin we will try to stick with the initial proposed schedule with a release on December 17 (option 1 below), unless critical bugs pop up in the coming two weeks.
>
> Thierry
>
>
>> On 23 Nov 2017, at 00:19, Thierry Crozat <criezy at scummvm.org <mailto:criezy at scummvm.org>> wrote:
>>
>> All,
>>
>> First I would like to thank snover for his amazing work getting the release process started by reviewing open tickets, making a list of blockers, and getting some of those fixed. As a reminder the release blockers list is available at <https://bugs.scummvm.org/report/16 <https://bugs.scummvm.org/report/16>>.
>>
>> It was also decided that the release version will be 2.0.0, which seemed to be the most popular choice, and snover made the changes in master yesterday while I updated the wiki.
>>
>> Today we made one more step by announcing testing.
>> That also probably means that we should all consider the trunk to be frozen for about a week until the 2.0 branch is created.
>>
>> I would like to come back to the original release scheduled proposed by Eugene though as we have announced testing 10 days later than what was in that proposal. Delaying the rest of the schedule by 10 days would bring us perilously close to Christmas to get the release builds done, and it may be a busy period for porters and packagers. A lot of work as been done already to stabilise the release, and we could try to compress a bit the testing period and either stick to the original schedule , or delay it by one week. Another option would be to delay the release until mid January.
>>
>> Option 1: Stick with original release date
>> ------------
>> November 12: Release cycle starts, testing announced
>> November 22: List of bugs published. Trunk is frozen
>> November 29: branch, trunk unfrozen, porters contacted
>> December 8, Fri: tagging, tarballs uploaded, porters start submitting their builds
>> December 17: Release
>>
>> Option 2: Delay by one week
>> ------------
>> November 12: Release cycle starts, testing announced
>> November 22: List of bugs published. Trunk is frozen
>> November 29: branch, trunk unfrozen, porters contacted
>> December 15, Fri: tagging, tarballs uploaded, porters start submitting their builds
>> December 24: Release
>>
>> Option 3: Delay release to mid-January
>> ------------
>> November 12: Release cycle starts, testing announced
>> November 22: List of bugs published. Trunk is frozen
>> November 29: branch, trunk unfrozen, porters contacted
>> January 5, Fri: tagging, tarballs uploaded, porters start submitting their builds
>> January 14: Release
>>
>> What do you think?
>> Do you have any other suggestions?
>>
>> Thierry
>>
>>> On 21 Nov 2017, at 01:16, Colin Snover <scummvm-devel at zetafleet.com <mailto:scummvm-devel at zetafleet.com>> wrote:
>>>
>>> All,
>>>
>>> As I have been working today on release prep, I have noted several
>>> places where the 1.10 version number has already been used, such as the
>>> wiki and forum and (of course) in the version numbers for the daily
>>> builds which are baked into the executable. Does anyone have an
>>> authoritative list of all the places where this would need to be
>>> changed? I don’t really want to delay the release any longer on this,
>>> but it seems like from reading feedback on this thread that most
>>> everyone would like to change the version number for the next release,
>>> and I don’t want to disappoint! (Unless getting the release out is more
>>> important to everyone, in which case I will just leave it as-is and
>>> we’ll roll with 1.10!)
>>>
>>> Thanks,
>>>
>>> On 2017-11-11 04:46, John Willis wrote:
>>>> Hi All,
>>>>
>>>>> Now, both SCI3 and Starship Titanic bugfixing is mainly over, thus
>>>>> I'd like to propose to launch the 1.10.0. Maybe we should call it
>>>>> 2.0.0?
>>>> Calling it 2.0.0 gets my vote as it is a milestone in terms of supported games.
>>>>
>>>>> I am not sure we can get enough testers at this time, but I'm leaving
>>>>> it open, and propose two schedules: with and without the extensive
>>>>> testing period.
>>>>>
>>>>> With testing:
>>>> With testing gets my vote.
>>>>
>>>> As a 'lapsed' porter trying to get his old ports fixed up I can see the merit in contacting porters/builders directly a little earlier than usual to try and ensure we have the widest set of builds ready to go. Especially if we go with a 2.0 release.
>>>>
>>>> Just my 2 pence, either way a new release seems like a good plan and is timely.
>>>>
>>>> Regards,
>>>>
>>>> John
>>>>
>>>> _______________________________________________
>>>> Scummvm-devel mailing list
>>>> Scummvm-devel at lists.scummvm.org <mailto:Scummvm-devel at lists.scummvm.org>
>>>> http://lists.scummvm.org/listinfo/scummvm-devel <http://lists.scummvm.org/listinfo/scummvm-devel>
>>>
>>>
>>> --
>>> Colin Snover
>>> https://zetafleet.com <https://zetafleet.com/>
>>>
>>>
>>> _______________________________________________
>>> Scummvm-devel mailing list
>>> Scummvm-devel at lists.scummvm.org <mailto:Scummvm-devel at lists.scummvm.org>
>>> http://lists.scummvm.org/listinfo/scummvm-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20171130/77b98a6a/attachment.html>
More information about the Scummvm-devel
mailing list