- Stronger wording around "use composer"
- Consistent domain and email address naming
- Removed example for publishing non-composer modules (those shouldn't be encouraged)
- Removed instructions for installing modules from archives
[ci skip]
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)
SCSS linting now uses the node-based sass-lint tool, since we’re
shifting away from CodeClimate.
This has the benefit of not requiring a ruby gem on dev tools -
everything is provided as npm dev dependencies.
This was also necessary to run the linting inside travis.
Responsibility for finding and referencing images and fonts is now
given to webpack. All the url references are now relative to the
component scss file, and point to font & images files in src/, rather
than assuming someone else will place them in dist.
This makes the source more modular, and makes it easier to, for
example, inline images are data URIs, or create a new build script that
builds several modules for a project in a single pass.
Workaround for bad font path in bundle.css:
ExtactTextPlugin didn’t work as well with a subfolder reference in the
filename. This is just a short-term fix and could probably be improved
to put bundle.css back in the styles subfolder.
Webpack handles images & fonts:
Responsibility for finding and referencing images and fonts is now
given to webpack. All the url references are now relative to the
component scss file, and point to font & images files in src/, rather
than assuming someone else will place them in dist.
This makes the source more modular, and makes it easier to, for
example, inline images are data URIs, or create a new build script that
builds several modules for a project in a single pass.
Clarify docs on spriting and webfonts:
We've decided to remove sprity since it comes with hundreds of dependencies,
and needs compilation within the "npm install" - dragging out the already overweight
install process, and making the resulting node_modules/ folder less portable between systems.
The bundle is generated by running “webpack” directly - gulp is no
longer needed as an intermediary. The resulting config is a lot shorter,
although more configuration is pushed into lib.js.
Modules are shared between javascript files as global variables.
Although this global state pollution is a bit messy, I don’t think it’s
practically any worse than the previous state, and it highlights the
heavy coupling between the different packages we have in place.
Reducing the width of the coupling between the core javascript and
add-on modules would probably be a better way of dealing with this than
replacing global variables with some other kind of global state.
The web pack execution seems roughly twice as fast - if I clear out my
framework/client/dist/js folder, it takes 13.3s to rebuild. However,
it’s not rebuilding other files inside dist, only the bundle files.
CSS files are now included from javascript and incorporated into
bundle.css by the webpack. Although the style-loader is helpful in some
dev workflows (it allows live reload), it introduces a flash of
unstyled content which makes it inappropriate for production.
Instead ExtractTextPlugin is used to write all the aggregated CSS
into a single bundle.css file. A style-loader-based configuration could
be introduced for dev environments, if we make use of the webpack live
reloader in the future.
Note that the following features have been removed as they don't appear to be
necessary when using Webpack:
- UMD module generation
- thirdparty dist file copying
LeftAndMain.js deps: Without it, ssui.core.js gets loaded too late,
which leads e.g. to buttons being initialised without this added behaviour.
It was getting a bit lost halfway down the contributing/code instructions,
in between the detailed git instructions.
Also reordered the docs TOC for that folder by renaming the files.
Also created a contributing/coding_conventions landing page separately from the PHP ones, since we now need to account for JS and CSS conventions as well
