Semanticmediawiki: 3.1.0 release

[mwjames]

Tracking issue for the 3.1.0 release.

• Release notes
• Open issues for 3.1.0
• 3.1.0 issues already closed
• Changes since 3.0.0
• Contributors since 3.0.0 https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/2694#issuecomment-333473589

TODO

• [x] #3918 3.1.0 pre-release activities

3.1.0 rc.1 - date 2019-09-04

• [x] Shape rel notes
  
  
  
  • [x] Add missing commits tagged with releasenotes
  
  
• [x] Update INSTALL.md - not just version number
• [x] Update composer.json
• [x] Update version number
  
  
  
  • [x] extension.json
  
  
  • [x] COMPATIBILITY.md
  
  
• [x] Create tag
• [x] Update semantic-mediawiki.org
  
  
  
  • [x] Run composer update
  
  
  • [x] Touch LocalSettings.php
  
  
  • [x] Update the SMW configuration
  
  
  • [x] Check Special:Version
  
  
• [ ] Ping testers group
• [x] Announce via mail
• [x] Do a release tweet on Twitter

3.1.0 rc.2 - date TBD / not done due to minimal number of issue reports

• [ ] Shape rel notes
  
  
  
  • [ ] Add missing commits tagged with releasenotes
  
  
• [ ] Update version number
  
  
  
  • [ ] extension.json
  
  
• [ ] Create tag
• [ ] Update semantic-mediawiki.org
  
  
  
  • [ ] Run composer update
  
  
  • [ ] Touch LocalSettings.php
  
  
  • [ ] Update the SMW configuration
  
  
  • [ ] Check Special:Version
  
  
• [ ] Ping testers group
• [ ] Announce via mail
• [ ] Do a release tweet on Twitter

SMW 3.1.0 - date 2019-09-23

• [x] Modify smwgUpgradeKey (DefaultSettings.php) to reference to the release date
• [x] Finalize rel notes (include contributors (git shortlog -sn 3.0.0...3.1.0)
  
  
  
  • [x] Add missing stuff tagged with releasenotes
  
  
  • [x] Check open issues
  
  
• [x] Update version number (3.1.0)
  
  
  
  • [x] extension.json
  
  
  • [x] README.md in /
  
  
  • [x] README.md in /docs/
  
  
  • [x] COMPATIBILITY.md (release date etc.)
  
  
  • [x] INSTALL.md
  
  
• [x] Create branch 3.1.x
• [x] Create tag 3.1.0
• [x] Update https://github.com/SemanticMediaWiki/IndividualFileRelease: https://github.com/SemanticMediaWiki/IndividualFileRelease/pull/9
• [x] Update semantic-mediawiki.org
  
  
  
  • [x] Run composer update
  
  
  • [x] Touch LocalSettings.php
  
  
  • [x] Update the SMW configuration
  
  
  • [x] Check Special:Version
  
  
  • [x] Update release template
  
  
• [x] Start development of new version
  
  
  
  • [x] Update "composer.json" (update "branch-alias")
  
  
  • [x] Update "extension.json" (new alpha version)
  
  
• [x] Announce on wiki
• [x] Add release to Wikidata
• [x] Update version on en, mw and wikiapiary
• [x] Announce via mail
• [x] Do a release tweet on Twitter
• [x] In case no 3.0.3 release is done revert back the version info on the 3.0.x branch

[JeroenDeDauw]

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

[kghbln]

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

https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/3918#issuecomment-520221031

[JeroenDeDauw]

@kghbln @mwjames what about these dates?

• RC1 25th
• RC2 September 1st
• Release September 8st

Can of course do it later (one week?) though I rather have a release sooner than later. Right now there is no stable release of SMW that works with MW 1.32 or MW 1.33. Plus a trillion enhancements users don't have access to ... usual arguments.

[JeroenDeDauw]

Basically I want to know if there are any blockers besides the release work itself (which includes fluffing the release notes and such)

[JeroenDeDauw]

Ping @mwjames

[mwjames]

RC1 25th
RC2 September 1st
Release September 8st

Ping @mwjames

Fine by me.

[mwjames]

what are the blockers for doing 3.1 from your side?

4260, Those tests needs to be merged before a RC and need to pass.

[JeroenDeDauw]

I've removed the now incorrect dates from the schedule.

I'm also stepping down my involvement in this release for now. Recent events demotivated me. I'm also really not keen on cleaning up the "release notes debt" once again, especially if everything indicates it will be more of the same next time around.

Will send a retraction of the announced release date to the mailing list soon based on what happens here.

[kghbln]

I am currently failing the community here so everybody please through the mud in my direction. I need this day to figure out how to best do this task which appears to be the only open for the actual release and when.

[mwjames]

4260, Those tests needs to be merged before a RC and need to pass.

I clean-up the mess, so this is fixed.

I am currently failing the community here so everybody please through the mud in my direction.

No, if the community wants to see a release happen it can help otherwise it doesn't, it is as simple as this. Now, if the current proposed dates don't fit the calendar then they don't fit and there is nothing to beat yourself over. This project relies on active contributions and if contributions don't happen then this is the end of the story.

I'm also really not keen on cleaning up the "release notes debt" once again,
Recent events demotivated me.

I could say the same but instead we do business as usual, fixing a problem isn't something to mull over it is something to fix.

[mwjames]

@kghbln I put in some overtime so that the RELEASE-NOTES have at least notes on each item mentioned, which should help you to get going and not hang you out to dry.

To clarify, and to be upfront clear, personally I don't need a release, so, if people scream that they need something they should put in some effort and stop pointing fingers. This extension only gets improved by action, and actions alone which can take different forms. Now, you say you cannot code, then this is fine just ask @kghbln as he accommodating and willing to guide users.

PS: I have been telling people over and over again, don't use the issue tracker as pin board to drop something and hoping that someone will act on it and get it done. Get involved and get things rolling, I won't be here forever and once I gone, well the rest is up to your imagination.

[JeroenDeDauw]

@mwjames some finger pointing is in order actually. It's not the communities responsibility to document _your_ changes. Your contributions are awesome and all, but you are putting the project in an un-releasable state. This might not be a problem for your own usage, but it prevents other people from using it. It even discourages people from contributing, since they can not have their own changes released. I think this situation is quite harmful to the project.

[mwjames]

@mwjames some finger pointing is in order actually. It's not the communities responsibility to document your changes. Your contributions are awesome and all, but you are putting the project in an un-releasable state

Wow, wow, what? I'm putting the project nowhere, nothing here depends on me. If people want to see a release happen, they should get involve and do it.

Don't paint the wall black here, if you want to see a release happen, just do it. Do not complain, act.

It even discourages people from contributing, since they can not have their own changes released.

Which changes are we talking about? I have been literally waiting to see PRs from people here but I have been disappointed again and again. I'm not talking about code quality changes, I'm talking about changes that create an impact, move the software, and have a lasting effect. This sort of change I have seen last was from Stephan in 3.0 and to a minor degree #3945 due to that that this was from a first time committer.

but it prevents other people from using it.

You are killing me here, no one prevents anyone here to see his or her changes merged, or released. Don't make such accusations.

[JeroenDeDauw]

Hey James, I see you added explanations for your changes to the release notes yesterday. Thanks, this is awesome.

At the moment we have the convention that master should remain usable, which includes things like

• CI checks should pass before merge into master
• New code should have tests
• No breaking changes for the user unless working on a major release
• Some level of code quality for new code

I'd like to explicitly extend that to include

• Changes should be mentioned in the release notes when applicable

That way we do not only keep master usable, we also keep it releasable.

Note: I'm not proposing we be super dogmatic/strict about these points. Small and temporary divergences from optimal are fine. And we have a long history of making exceptions for new contributors with things like tests, which makes a lot of sense.

Does the above sound good? It's very close to what you are doing already and it would remove the grump from my side.

[kghbln]

This task is assigned to me from the start so I could have followed up in chunks which I did not. :(

Anyways we are ready for the rc and I will allocate some time and will probably do it this afternoon.

In general I am unhappy on how this went here.

[kghbln]

I will release without doing the rc.2. We only had one serious issue report for rc.1 and this one was fixed.

[JeroenDeDauw]

@mwjames can you reply to https://github.com/SemanticMediaWiki/SemanticMediaWiki/issues/3919#issuecomment-527248992?

[kghbln]

Just prepared the release announcement. I am ready to continue on the list once the pull was merged.

[kghbln]

@JeroenDeDauw Could you to the tweet?

[JeroenDeDauw]

@krabina is too fast https://twitter.com/i/moments/1176463539659268096 ;)

[krabina]

I'll leave you facebook gladly...

[JeroenDeDauw]

YouEvilPerson.gif

[JeroenDeDauw]

@kghbln did you mail mediawiki-l yet? If not, you want to do that or shall I?

[kghbln]

did you mail mediawiki-l yet?

I have done this yesterday too

[kghbln]

Thanks a lot @jaideraf for doing the last open points. Thanks a lot to everybody. I love you all!