Hello, As I was discussing with Aginor on IRC earlier, it has been quite a while since the last development version (far longer than I originally intended), and while the SDL 2 branch is more or less ready for merging, there are a few changes in master that could benefit from being tested separately from SDL 2, including:
* The [foreach] and [for] WML tags. * The new [message] implementation. * The Windows behavior changes (combined log in <user data>\logs, removal of the userdata-on-install-dir option, etc.) * zookeeper's new water graphics. * The default value syntax in variable interpolation. * Etcetera. What do you think of a new development release on the 11th of December? Failing that, the next option is the 18th. I would like to get it out *before* the week of the 24th to avoid keeping packagers busy during the holidays; for that reason, it's unlikely there'll be any development releases until January 8th at the earliest. *** Additionally, I've been considering moving us to a time-based release schedule for development and maintenance releases, in order to keep a constant stream of features and bug fixes coming to UMC creators instead of piling it all up at once like we've done thus far. Under the new scheme: * A new maintenance release from the current stable branch would be tagged every two months, on the third Friday 00:00 UTC; meaning that there would be an automatic string freeze every month starting from the second Thursday 00:00 UTC. * A new development release would be tagged every month, on the first Friday 00:00 UTC, except for betas and RCs for the next stable series, which would come every two weeks instead. Of course, this plan would require some degree of commitment from our mainline packagers (loonycyborg (Windows) and ancestral (OS X)), and I don't know yet whether this is feasible for them. Developers would also have to commit to not pushing incomplete or broken features that would affect shippability of the next development release, or at the very least making it possible to easily disable them at the last minute if time runs out. And because we can't have infinite development releases forever, this plan will also require us to put a list of features together *NOW* in advance, including items which should be completed before a prospective feature freeze for 1.14. I've made a page on the wiki with a tentative list: http://wiki.wesnoth.org/DevelopmentRoadmap ... which also happens to include a tentative freeze date, August 2016. There is a specific reason I chose this, which is the next Debian stable freeze being on December 5 2016. *** An important point that needs to be settled ASAP is whether we'll participate in next year's GSoC. Mentoring organization applications will be accepted from February 8 to February 19, so we must have an action plan ready before then. https://developers.google.com/open-source/gsoc/timeline In particular, we will need project ideas, mentors, and administrators. I can't really dedicate time to GSoC myself, so the GSoC admin will have to be someone else entirely (Ivanovic?). Likewise, I won't be able to volunteer to be a mentor since that would literally kill me. Of course, we can also decide to not participate in GSoC, which would make things easier for everyone, but at the cost of a precious missed opportunity. *** So, what are your opinions on these three points? Please note that while I will consider your silence regarding 1.13.2 as tacit approval like always, I can't really do the same about the other two subjects; I _need_ your feedback. -- Regards Ignacio R. Morelle <shadowm> _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
