[Scummvm-devel] Proposed schedule for 2.0.0

[Colin Snover]

criezy,

Thank you so much for your kind words and assistance with the release!
And another *huge* thank you to everyone who has been helping to tear
through the release blockers list with testing and bug fixes. We’ve gone
from around 35 identified crashes, lock-ups, and memory leaks down to
just 9 as of today.

For the schedule, I think that a balanced approach will be to just stick
to the original release date unless we suddenly get a swarm of new
critical bugs and decide that we need to push the date to take care of them.

Per a brief conversation on IRC I was hoping to not have any master
branch freeze, but I realised later that until the new Buildbot is
finished we’re stuck keeping the master branch frozen since that is the
only branch that Buildbot builds right now, and we rely on Buildbot for
publishing new testing releases for users.

Best,

On 2017-11-22 18:19, Thierry Crozat 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>.
>
> 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
>>
>>
>> -- 
>> Colin Snover
>> https://zetafleet.com
>>
>>
>> _______________________________________________
>> Scummvm-devel mailing list
>> Scummvm-devel at lists.scummvm.org
>> http://lists.scummvm.org/listinfo/scummvm-devel
>
>
>
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.scummvm.org
> http://lists.scummvm.org/listinfo/scummvm-devel


-- 
Colin Snover
https://zetafleet.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20171122/cee8ed53/attachment.html>