View in #core on Slack
@Viktor: Anyone around for the meeting?
I think the main agenda item for today was the 1.6.0 RC1. Is that still something we can do?
I shared some text feedback on the PR:
https://github.com/ClassicPress/ClassicPress/pull/1244#issuecomment-1625540799
@Matt_Robinson: Is there anything else for 1.6.0? Or just the new Dashboard Widget?
@benlumia007: 1.6.0 is only PHP 8.0
@Simone_Fioravanti: Repeating myself, but I see no deprecations for PHP.
@Matt_Robinson: There were some commits in June. I can amend the PR if we can have some very specific wording changes laid out for me - I’m multitasking here so I need this to be very basic (for me).
@Simone_Fioravanti: A message like ‘In v. 1.6 PHP below 7.4 is deprecated’.
@ElisabettaC77: it would be bettere worded like “v 1.6 deprecates PHP 7.4 and below, only supporting PHP above 7.4 from this release on”
@Viktor: OK, give me a moment and I will update text.
@Simone_Fioravanti: Yes, just an example. But this is >=7.4 not >7.4.
@Viktor: So we’re deprecating 7.4 too? Just confirming.
@Simone_Fioravanti: No, 7.4 is good in v2.
@Viktor: Oh, sorry I think I misread > 
@ElisabettaC77: I thought we were deprecating it also… sorry for the misunderstanding
@Matt_Robinson: @Viktor - are you going to amend the PR? I have an uncommitted fix from Tim that needs adding also.
@Viktor: No, I was editing my comment which has all the text.
Is this easy to understand? “Deprecation notice: Version 1.6.0 is the last version to support PHP 5.6 - 7.3. The minimum required version for 2.0.0 will be PHP 7.4.”
@Simone_Fioravanti: Sounds good. I’ll just change 1.6.0 to 1.6.
@Matt_Robinson: Some of that re-orders some conditional checks, I can almost certainly do it but not fast.
Also, do we need an RC for 1.6.0?
@Viktor: If it makes it easier, I would reduce it to two versions: Pre-v2 and post-v2. Right now there’s 4 different versions because of multisite.
@Simone_Fioravanti: Don’t think we need an RC: https://github.com/ClassicPress/ClassicPress/compare/1.5.3+dev...develop
@Viktor: Once the last PR is merged, I think we just need to test it and make sure everything works. And release it without RC.
@Matt_Robinson: There are 4 versions for pre and post v2 but also based on current_user_can( 'update_core' ) - it could cause issues directing users to update if they don’t have the capability within the WordPress roles system.
@Viktor: I think we don’t need notices for non-admin users.
As an admin, I wouldn’t want my users to see that notice.
@Matt_Robinson:
So, are we suggesting that this widget in any form only gets show to people who can update core?
@Viktor: I think that’s enough.
We’re not offering a filter to disable it, so an admin wouldn’t be able to disable it even if they were planning on upgrading to v2 when it comes out. That would worry users without a reason.
@Matt_Robinson: Reordered a little and the core update check is done to make the Widget load (or not) now.
@Simone_Fioravanti: Testing on a site with italian configured. Maybe we can remove i18n from this, because I got the whole message in english, except for the date…
@Matt_Robinson: Can we get any translation files updated in time for the release if we leave the translation in? It is good practice.
I’ve just pushed a code update with the changes as per my last screen grab.
@Viktor: Do we know what needs to be done for translations? I barely started scratching the surface with translations for v2
@Matt_Robinson: I am ashamed to say, as a native English speaker, that I have no idea 
I can code so it can be translated and can create POT files if needed but after that I’m not sure of the process for getting the translation files created and published.
@Viktor: We have Crowdin for that, but we haven’t touched it yet.
@Matt_Robinson: So, do we need a new translation template for updating before we launch, or do we go ahead and hope the translations are updated later?
@ElisabettaC77: there was a process involving uploading the sources to Crowdin, then revising and approving the ones that do not pass, and then actually translate and apprive the new ones. James usually did the transfer of the sources, and as of now the old ones should still be there, not aligned. In the process at a certain point he also kicked me out of the team on Crowdin, so I do not have access to manage that. I can provide strings for the Italian version. The issue with translations is an Italian speaker native can’t review other locales IMHO and in the first place at the time people said they would help and never showed up (and I am not the kind of person who goes to wake up the hubby because he forgets to wake up for work, and I am not the kind to do it all myself, and also covid happened). I can help, but if people say they are going to help too they need to make themselves accountable.
@Matt_Robinson: That sound to me like a vote for just release and worry about the translations later. Perhaps well in advance of v2 we also need to review who has access to translations, how it is granted and get it updated and working more effectively.
https://github.com/ClassicPress/ClassicPress/pull/1244
Is this okay to merge now?
Just waiting for the last PHPUnit check to complete.
@Viktor: Sorry, had a phone call. I’m slowly working on figuring out translations for v2 and already figured out how to get the strings from the core. But for 1.6.0, we can skip it.
@Matt_Robinson: Okay, that is merged, checked need to run on develop then we can make a 1.6.0 release. I don’t have time today, happy if another release lead wants to do this or I might get time this weekend.
@Viktor: I’ll try testing develop branch. We’re not in a rush, so whoever is doing the release can do so at their convenience.
@Simone_Fioravanti: I’ll prefer you do the release 
@Matt_Robinson: Okay, all good, 1.6.0 just needs releasing, I’ll try to find some time for that this weekend if I can but it’s a busy one.
@Viktor: No worries, do it when you can.
Thanks everyone. Good meeting.
@Simone_Fioravanti: Thanks 