- 🇳🇿New Zealand quietone New Zealand
It seems to me that this has been resolved by the answers in #4 and #6. And there is also drupal/core-recommended, https://github.com/drupal/core-recommended.
I am going to close this as outdated.
We have a lot of great libraries in Drupal 8 now, which is awesome. It's somewhat confusing why were aren't being explicit about the precise version we're using.
While we're developing and getting Drupal 8 ready, it kind of makes sense why we're using wild cards for the version numbers of the libraries we're using. That makes it easier for us to update our libraries and push out a fresh patch updating everything (which is great, as long as that doesn't break anything).
But once Drupal 8 enters into beta stage we need to be mindful of what versions we want to ship. Should we promote a development methodology where we allow Drupal developers to update their libraries without concern (for example at the start of a new project).
Or should we ship Drupal with specific version (specific now to the patch version: MAJOR.MINOR.PATCH)? And thus promoting a methodology of keeping the vendor libraries we ship alone (unless you really know what you're doing).
For the most part I just want to resolve a pet peeve of mine where I can run "composer update" in the root of a Drupal 8 site and get a ton of updated files.
That's what I think should be our policy here: Executing "composer update" in the root of a Drupal 8 site shouldn't update anything because the version we list in composer.json are completely explicit so that there is no misunderstanding about what versions we're using.
Closed: outdated
11.0 🔥
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
It seems to me that this has been resolved by the answers in #4 and #6. And there is also drupal/core-recommended, https://github.com/drupal/core-recommended.
I am going to close this as outdated.