I believe the example needs more than just whether it has an alpha or beta tag. Versioning can affect whether it will go to another release, and according to the composer docs acts differently if it is a pre-stable release, as in version 0.x
From: https://getcomposer.org/doc/articles/versions.md
// ~ | allows last digit specified to go up
"vendor/package": "~1.3.2", // >=1.3.2 <1.4.0
"vendor/package": "~1.3", // >=1.3.0 <2.0.0
// ^ | doesn't allow breaking changes (major version fixed - following semver)
"vendor/package": "^1.3.2", // >=1.3.2 <2.0.0
"vendor/package": "^0.3.2", // >=0.3.2 <0.4.0 // except if major version is 0
I'm not saying that there can't be any bugs in composer's upgrade calculation. And in their list, 2.0.0-beta1 is less than 2.0.0, so can it decide to upgrade to the 2.0.0-beta1 from 1.x if your minimum stability is beta, and your restriction is ~1.0, because 2.0.0-beta1 is < 2.0.0?
I agree that if minimum-stability is stable, but the individual requirement is ^2.0.0@alpha that it should upgrade from 2.0.0-alpha1 to 2.0.0-beta1, and possibly even to 2.1.0-beta
And if your individual requirement is ^2.0@alpha that it should even upgrade to 2.1.0-alpha1, or higher, according to the docs.
But if the individual requirement is 2.0@alpha, does that lock it in at alpha levels because it didn't have a ^ or ~ ???
Without documenting the actual requirements, we don't know if it was other restrictions that caused it to fail to upgrade.
Steps used to setup test project in DDEV:
mkdir testpb
cd testpb
ddev config (using defaults)
ddev composer create drupal/recommended-project (installed Drupal 11.1.5)
ddev config --docroot=web --project-type=drupal11
ddev restart
ddev composer require drush/drush (installed Drush 13.4.0)
added "drupal/project_browser": "2.0.0-beta1", to conflict section in composer.json to ensure an alpha install, since beta1 is current release.
ddev composer require 'drupal/project_browser:^2.0@alpha' (installed Project Browser 2.0.0-alpha10
ddev drush si (using defaults)
ddev drush en project_browser
ddev composer require drupal/automatic_updates:^3 (installed Automatic Updates 3.1.7)
ddev drush en automatic_updates
Went to Reports-Available Updates, clicked on manual run, and it displayed the Project Browser beta1 as available on the List tab.
On the Update tab, it showed "No update available".
Removed the conflict in composer.json for Project Browser beta1.
Reran the manual check... and got the error message that composer.json does not match the .lock file and to do a composer update.
Ran a ddev composer update --lock to get past that.
Reran the manual check and still got the message that there were no available updates.
The composer.json line for Project Browser is: "drupal/project_browser": "^2.0@alpha"
And the stability flags are: "minimum-stability": "stable", "prefer-stable": true,
The composer require for Project Browser was taken off the Alpha10 release page.
Any further changes suggested?
Is there a way to monitor their commits to quickly see if they do anything malicious? That could permit an immediate suspension. And have they applied for any abandoned modules?
gábor hojtsy → credited warped → .
hestenet → credited Warped → .
Aren't you adding a bunch of packages when you add the dependencies?
At some point, it must have what is going to be done. Jumping to a display, and then returning to the point where it evaluates, if there are any changes, sounds like minimal intrusion. But I don't know the process is.
In Linux, when you install a new package, it shows you the dependencies that will be added to the install, and optional modules that would enhance your experience. Those would require additional install commands later.
I have aborted installs just because I didn't realize how many additional packages would be installed. Having a preview page would definitely give new to Drupal the confidence that they are more in control. More information makes it understandable, rather than wondering what it is going to do. Think about someone that sees a module for credit card processing and doesn't realize this will install commerce.
On the preview page, it could also indicate if it was going to download the module, upgrade an existing module, that maybe wasn't enabled, or just enable a module. After all, a module could have been uninstalled previously and not removed, but they didn't know or remember. Or one of the dependencies might be to enable a core module.
This adds to the idea that the button can just be a "Install" button, instead of a "Download & Install", or "Add and Install", because the exact procedure is detailed in the status and you don't have to know up front.
I also like @lostcarpark 's idea of a post install display. Not only can it include setup/config links, but if an upgrade had change notes, or requirements to manually make changes because of an update, that would be a great time to inform them, rather than leaving them to wonder why it isn't working. And a great confirmation page for a screen print to document their setup, and steps they used to get there.
While project browser is a feature all may use, the intent is to make it easier and more comfortable for those with little knowledge of Drupal. Maybe an opt-out config would help those more knowledgeable to disable features they don't want.
brianperry → credited Warped → .
It might be overwhelming, when you enable them, if you have many debug messages. I like the debug message function, but maybe a checkbox on each one to enable, and a button to disable all. Maybe as an option on a "save" dialog, to remind you to disable when you save the setup.
At the Alpha stage I can see wanting to keep parts required in core at a minimum. Just thinking that for general release, it would be good to support beginners by reducing problems they may initially encounter.
I agree that hosting features are not likely to be removed, but if they aren't there in the first place, are unlikely to be added by cheap hosters. I had difficulty getting PHP 8 added a year ago by a client's cheap hoster. They said they had no plans for it, and only when i asked if we would need to Seek hosting somewhere else, did they grudgingly install it in our shared environment. Only later did they install it where it was available in CPanel. And dropping Drupal ad a 1-click install sounds like the path of least resistance for them, if customers run into, and report any problems with using Drupal, that point to them needing to change hosting configuration and requirements.
I understand trying to keep core minimal and less stress/work to keep it maintained. Maybe if there is a default "Recipe" that can pull in all the basic contrib needed to create a workable website, one that can conditionally check hosting services, that would make entry level easier to start, while allowing many core modules to be removed to contrib.
Just a few thoughts.
1. Are you thinking that most sights will use AU? If not, then are the likely users less likely to be using local development to update and test, more likely to set and forget, assume that a core service will just work, and have more difficulty when it doesn't.
2. Should new users be presented with options that just work, instead of needing to immediately jump into the Drupal contrib system. Core Drupal allows a pretty good basic website, before venturing into contrib.
3. If cheap hosting doesn't have rsync, will they remove Drupal as a 1-click install option? I have seen cheap hosting with WP, but not Drupal. Since they are often very slow to update Drupal, this seems like a great opportunity to improve using Drupal in those circumstances.
4. Is there no other tool or method, besides trying to duplicate rsync in PHP, that would require less maintenance?
5. Are we improving the experience for those new to Drupal, or for those that don't even know what Drupal is, and are just trying it out of several options.
hestenet → credited Warped → .
It is nice to have a page of recommended versions of PHP and database versions, but historical information must also be available. Just because D8 and D9 are EOL doesn't mean the info isn't needed anymore. People are still getting old websites to update and are being wrongly informed that D8 can be changed to PHP 8.1 before upgrading to D9. To minimize the impact of changes, it is easier to upgrade D8 at PHP 7.4 to the latest of everything, then upgrade to D9.0.latest, then D9.1.latest, etc, until D9.5.latest at PHP 7.4 unless some module requires it. Junk hosting is notorious for not updating, and some have just provided PHP 8 versions, while others are still at PHP 7.4 and still running latest D9 versions. Upgrading D9 latest to PHP 8.1 is probably the best time, when all other problems have been solved, before possibly adding several more PHP issues. There is still a D7 PHP requirements page, probably because it is still supported, but there should still be a D8 and D9 page with complete information. As in when certain versions of PHP started being supported. Supplying this archival info will result in fewer questions in support channels as well as making it easier to point people to the correct information, instead of hopefully getting someone that actually knows, instead of misinformation.
Something that may create an issue with a few sites is LibreSSL, a fork of OpenSSL that removes older, insecure protocols, is lighter weight,and is preferred in some Linux distributions. Below is a link on configuring PHP7 for LibreSSL. IDK if it has gotten any easier in recent times.
Another problem to check is that certificate validation often doesn't check if it has been revoked.
https://stackoverflow.com/questions/43942717/build-php-7-using-libressl#...
hestenet → credited Warped → .
Chris McGrath → credited Warped → .
Chris McGrath → credited Warped → .
Chris McGrath → credited Warped → .
hotwebmatter → credited Warped → .
hotwebmatter → credited Warped → .
hotwebmatter → credited Warped → .