Semanticmediawiki: 3.1.0 pre-release activities

Created on 13 Apr 2019  路  25Comments  路  Source: SemanticMediaWiki/SemanticMediaWiki

Tasks and activities

  • [x] Define supported PHP range --> PHP 7.0 - 7.3
  • [x] Define supported MW release range --> MW 1.31 - 1.33

    • [x] All tests pass on the selected MW release

  • [x] Change .travis.yml to reflect defined boundaries - done with https://github.com/SemanticMediaWiki/SemanticMediaWiki/pull/4135
  • [x] Change compatibility matrix to reflect defined boundaries
  • [x] Move PRs older than 90 days marked as enhancement or feature request to https://github.com/SemanticMediaWiki/SemanticMediaWiki/projects/4
  • [x] Check and extend RELEASE-NOTES.md

    • [x] All links in the RELEASE-NOTES.md are reachable (having a corresponding wiki page, are valid etc.)

  • [ ] Verify that project maintained extensions to pass tests with the 3.1 pre-release version

    • #3896 (Create CI job to run with some extra extensions)

    • List of project maintained extensions ...

  • List deprecated

    • Functions and classes

    • Settings

  • List removed

    • Settings

  • more ... (extend at will)
roadmap

Most helpful comment

I want to see #4226 being shipped but want to sit on it for a week or so.

Is done now.

So, the CI shows a pass on all queues.

image

Tests: 7481, Assertions: 19989, Skipped: 55.

All 25 comments

@mwjames What is your suggestion about PHP and MW ranges?

What is your suggestion about PHP and MW ranges?

  • PHP 7.0 - 7.3
  • MW 1.31 - 1.32 (1.33 has unresolved issues and tests are failing, so unless someone fixes them I don't see 1.33 being officially supported)

PHP 7.0 - 7.3

Sounds good.

MW 1.31 - 1.32

Sounds good, too.

1.33 has unresolved issues and tests are failing, so unless someone fixes them I don't see 1.33 being officially supported

I know that this is utterly painful and I also know exactly how you feel, however I believe we should somehow get 1.33 in since this is the branch which is going to be released end of June. On the other hand we could do SMW 3.1.0 and see how things go until the release of 1.33.0 and do a SMW 3.1.x release bringing support. Probably the latter is the most pragmatic approach. If I had the means I would try to fix but this is out of my personal reach.

MW 1.33 seems to be alright too.

Apart from #3626 all blocking tasks seem to be done. Note that I am deliberately ignoring the docu task when mentioning this.

MW 1.33 seems to be alright too.

Very well, if you think it works then I'd say go ahead.

Very well, if you think it works then I'd say go ahead.

The error logs are empty when it comes to SMW. Actually I am astonished how few issues there are.

3626

I forgot about the reason for the holdup to do this one.

3801

I do not know how far you got here. In any case you did an incredible job.

3801

I do not know how far you got here.

This is just a collection task, should be closed together with the 3.1 release.

Since SMW is still compatible with 5.6 this late in the process I propose we keep 3.1 compatible with 5.6. That way people on that version can get a years worth of features. If 3.1 happens in the next weeks that is a low cost to us.

At the same time I suggest we immediately start using 7.1 features after the release. The cost incurred by not using 7.0 features in this release so far is in my estimation _much_ higher than any backport hassle. Scalar types and return types are huge, and now we have one year worth of work that does not use them.

Blockers I see (not mentioning my complete failure to document):

All the rest can probably be moved forward to 3.2 and beyond.

Since SMW is still compatible with 5.6 this late in the process I propose we keep 3.1 compatible with 5.6.

By the time of #4135 I may have subconsciously started to use PHP language features only available with 7+ therefore I can no longer state with confidence that SMW runs on PHP 5.6. To cut the story short, MW 1.31 requires 7+, SMW requires MW 1.31 ergo SMW requires 7+.

SMW 3.1 and 7.1 is a bit too early for stated reasons listed in https://github.com/SemanticMediaWiki/SemanticResultFormats/pull/507#issuecomment-515687417.

Declaring SMW 3.2 to require 7.1 (even though the lower bound is MW 1.31) seems fair to enterprise and institutional users.

2343

I see that as a nice to have but not as a real blocker since it requires changes in code (while limited to the legacy Settings.php part and DefaultSettings.php) and documentation. In any event, the dashboard will inform users that certain settings are deprecated and can be removed in future without further notice hence they should not expect those setting(s) to work beyond SMW 3.1 even though the setting hasn't been removed yet.

@mwjames what are the blockers for doing 3.1 from your side? Anything that still definitely should be included?

I want to see #4226 being shipped but want to sit on it for a week or so.

By the time of #4135 I may have subconsciously started to use PHP language features only available with 7+

https://travis-ci.org/SemanticMediaWiki/SemanticCompoundQueries/jobs/570507561

+echo 'putenv( '''MW_INSTALL_PATH=/home/travis/build/SemanticMediaWiki/mw''' );'
+php maintenance/update.php --quick
PHP Parse error: syntax error, unexpected '(' in /home/travis/build/SemanticMediaWiki/mw/extensions/SemanticMediaWiki/src/MediaWiki/Deferred/CallableUpdate.php on line 349

Above is an example where PHP 5.6 no longer works with SMW 3.1 because instead of call_user_func_array( ... ) we just call ( $this->callback )() which doesn't work in PHP 5.6. In short, SMW 3.1 is no longer compatible with PHP 5.6.

I want to see #4226 being shipped but want to sit on it for a week or so.

Is done now.

So, the CI shows a pass on all queues.

image

Tests: 7481, Assertions: 19989, Skipped: 55.

Not sure if the need a project for long standing bugs but probably it will be good to have one to accompanying the working scheme we currently have for enhancements or features? Anyways I have cleared heaps of issue and moved them to the respective projects for pick up and or information.

Where is this approach of closing issues and putting them on a board coming from? Are some other projects also doing this?

@mwjames what are, from your PoV, the highlights for 3.1?

Where is this approach of closing issues and putting them on a board coming from? Are some other projects also doing this?

Do not know if somebody else is doing this however SMW is doing for for two or three years now after adopting the rudimentary project management capabilities GitHub started to offer. Helps keep focus in a way.

To avoid having to explain this approach over and over again, see

3629 which reflects on the approach.

PS: There is actually a bot in Github (probot) that helps with
workflows like closing inactive issues, so yes, others approaching the
problem of "dead" issues in a similar fashion.

On 8/22/19, Jeroen De Dauw notifications@github.com wrote:

Where is this approach of closing issues and putting them on a board coming
from? Are some other projects also doing this?

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/3918#issuecomment-523791927

@kghbln what is still left todo? Since you have a whole bunch of stuff on your plate maybe I can do some of the things instead.

The only thing I cannot really do is "List deprecated functions and classes". All the rest is done en passant while prepping my presentation.

I suggest we just drop that. Not clear it delivers value to anyone. I don't recall anyone asking for that back when we where not listing these and would not trust such a list to be accurate myself.

Could have fit into a technical section or so. Was hoping that some magic git list --deprecated would emit such things. :)

Verify that project maintained extensions to pass tests with the 3.1 pre-release version

Let's put it like this. Sandbox does not fatal. I know this is not perfect.

Create CI job to run with some extra extensions enabled

3896 is still up for grabs. I do not really have time to dig into this but rather focus on documenting, which I badly neglected lately.

List of project maintained extensions ...

Basically the ones included in the https://github.com/SemanticMediaWiki/SemanticBundle excluding Page Forms, Maps and Modern Timeline though the latter two may be recognized as quasi supported

List removed settings

Ouch, just wanted to get this off the ground. In the end we have a safe fail via special page "SemanticMediaWiki". Probably we should note somewhere on Upgrade that one should check this on wiki

Probably we should note somewhere on Upgrade that one should check this on wiki

We are better than I thought: already mentioned

Was this page helpful?
0 / 5 - 0 ratings