Time for 1.14.6?

Discussion among members of the development team.

Moderators: Forum Moderators, Developers

Post Reply
User avatar
josteph
Developer
Posts: 740
Joined: August 19th, 2017, 6:58 pm

Time for 1.14.6?

Post by josteph » December 23rd, 2018, 5:01 pm

Is it time to release 1.14.6 yet? There have been multiple reports of top bar issues (#3714, f78887fb1665cf5ab82d7b08c50fb583b2605e7f, 461cd2c4bdeb2eb0e84ede6e57cd0b315dee2cee), nemaara's major revisions to TSG and THoT (#3648, #3126) have been merged, and there's a bunch of other changes in changelog.

Tad_Carlucci
Developer
Posts: 475
Joined: April 24th, 2016, 4:18 pm

Re: Time for 1.14.6?

Post by Tad_Carlucci » December 23rd, 2018, 8:59 pm

Was wondering the same thing myself.

I've not run through the Github milestones for 1.14.5/1.14.6 items which are still in process. Someone should and re-triage them to 1.14.7 or 1.15 (and, yes, we need to talk about whether there should be a 1.14.7 or if 1.15 is nearing readiness, too).
I forked real life and now I'm getting merge conflicts.

User avatar
Iris
Site Administrator
Posts: 6587
Joined: November 14th, 2006, 5:54 pm
Location: Chile
Contact:

Re: Time for 1.14.6?

Post by Iris » December 24th, 2018, 2:55 am

For the nth time, there is no need to talk about whether there should be a 1.14.7. There must be more stable releases as needed until the next stable series is released, which is obviously not going to happen within the next 6 months. Of course you can’t force stable releases to happen if there aren’t any significant fixed bugs, and you can’t force volunteers to fix bugs, but ideally Wesnoth should be releasing a stable release every two months.

All that said, what really needs to happen is for the project to have a little more organization with regards to the stable release pacing and make up its mind with regards to the content that goes into them so its impact on translations can be adequately controlled.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.

User avatar
josteph
Developer
Posts: 740
Joined: August 19th, 2017, 6:58 pm

Re: Time for 1.14.6?

Post by josteph » December 24th, 2018, 4:09 pm

https://github.com/wesnoth/wesnoth/issues/3688 is milestoned 1.14.6 and labeled blocker, but I think it only affects master so it should be re-milestoned to 1.15.0. Other than that, there are no issues milestoned 1.14.5/1.14.6 with showstopper labels (blocker/regression/urgent).

User avatar
Pentarctagon
Forum Administrator
Posts: 4093
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Time for 1.14.6?

Post by Pentarctagon » December 24th, 2018, 4:26 pm

Someone would need to confirm that it does definitely only affect master.

edit-
Actually, if I pay more attention to the issue linked, there's also:
https://github.com/wesnoth/wesnoth/issu ... -431486421
pofix update on the other hand make a lot more sense. By the way I fear that something is broken (or at least was broken) recently in stable with the pofix generating a duplicate string which creates a broken translation... Yes, pofix is a powerful tool but you need to be very careful because any creation of a duplicated source string is a major breakage in the po files... This is the reason why you should always apply pofix.py to all po and pot files after making them. And no, that change commit does not have to be applied, just the change to pofix.py and then running it on master and making sure that all translation files still build.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code

User avatar
josteph
Developer
Posts: 740
Joined: August 19th, 2017, 6:58 pm

Re: Time for 1.14.6?

Post by josteph » December 26th, 2018, 4:40 pm

Ah, so it affects 1.14. I assumed it was master only.

Running pofix on 1.14 I get this error:

Code: Select all

pofix: po/wesnoth-help/pl.po already includes the new string
        "However, the few implements"
but also the old
        "However the few implements"
this needs handfixing for now since it likely creates duplicate msgids.
Is that what we need to fix? The string occurs with comma in the msgid and without comma in the msgstr (that part isn't translated), so can we just add that comma to the msgstr and check this blocker off?

Post Reply