We have too many docs to list these out now,
even in 3.x this was a bit of a stopgap solution.
Point to a centrally managed URL on silverstripe.org
instead, where we can update the list of "core modules" regularly
without breaking URLs in the docs etc
Note that these URLs are also used internally by the
Open Sourcerers team.
JIRA isn't fully under the OSS team's control,
and played up in the past (Dan couldn't move issues).
Since Github has project boards now, and we're paying
for private repos on github.com/silverstripe-security already anyway,
there's no reason to introduce another tool (JIRA) into our workflows.
No need to move existing issues, the JIRA board hasn't been used in a while.
Which leads to unclear ownership and status of security issues,
and is exactly the reason for this change ;)
API Remove Director::$test_servers / $dev_servers
API Remove MODULES_PATH / MODULES_DIR constants
ENHANCEMENT Injector backtick syntax now supports environment variables as well as constants
Fixes#6588
SQL Server is still community supported, and we have IIS 7+ in our “server requirements”, which won’t change.
But the WebPI installer is rarely used in practice, and doesn’t provide the best user experience for Windows users
compared to other installation options. Given it sucks up time on every release process. this should be removed.
The role moves around based on current availability.
@tractorcow has done most of the last releases,
but a separate team (headed by @dhensby) will be
responsible for 3.x releases.
There's not really much point to declaring a release maintainer,
unless there's disagreements in the core team where we need
an arbitrator. So far those conflicts have been resolved
on individual tickets (e.g. what should go into a release),
and the process for that seems to work well.
The "repositories" key makes "composer update" ridiculously slow with the amount of tags and branches we have in core,
so unfortunately we can't rely on it. I've also removed the thinkapp-based instructions about working with git,
since it's now fairly widespread knowledge, and better documented elsewhere.
Note that I've chosen to rename the "origin" remote to "upstream" in order to keep in line with
the contribution documentation on help.github.com (even if it's a bit more clumsy to explain upfront)
