That depends on several factors. Here are some pros and cons of each:

It is not recommended you do this because you may run into issues. For example, some changes were made in crypto_master.php and data/upgrader2.php prior to the first v11 alpha. These changes will result in a broken upgrade unless you already pulled these changes from git. Similar situations could happen in the future as well.

It is recommended you either discard the git install and use a fresh install from the Downloads, or to maintain a git install and a bleeding-edge release install separately. Do not combine the two.

Absolutely! Frequent changes may be made to both bundled and non-bundled addons. Bundled addons will be updated via the upgrader. For non-bundled addons, you will have to update them through the addons management screen (Admin Zone > Structure > Addons). You will be informed which ones need updated.

Once version 11 reaches release candidate, we do not expect frequent updates to non-bundled addons anymore. But it is still good practice to check after every update.

Yes, for basic non-custom v10 sites. However, expect some issues to arise in the process. And please report those issues to the tracker.

For v10 sites with non-bundled addons or customisations, upgrading to v11 will likely break the site until you update the non-bundled addons or temporarily remove the customisations.

We aim to have the upgrader fully functional for a large majority of types of sites and for sites using non-bundled addons by the time version 11 reaches release candidate stage.

We do not recommend upgrading production v10 sites at this time until v11 reaches stable.

Yes (probably). Always remember especially during alpha and beta phases that things can break. Please make backups first. And let us know on the issue tracker if an issue occurs.
 

Note: You cannot upgrade from 11 alpha to 11 beta without first upgrading to 11.alpha4 (if you are not already on 11.alpha4).

As of July 22, 2024, we entered beta status where our focus is now smashing bugs and stabilising the software. All planned features have been implemented for 11.0 (and most others deferred to 11.1 or later), though we may still merge in a few minor features or tweaks. The upgrader has been tested on a typical non-custom v10 site.

We will be releasing several beta versions in the beta phase.

We do not know when we will be able to release the first Release Candidate or stable versions at this time.

These plans are all subject to change without notice.

• Confirmed: When you actively log in with your credentials.
• Non-confirmed: When you return to the site and are automatically logged in via cookies.

• Choose a Secure Host: Opt for hosts that offer suEXEC and open_basedir for better account isolation.
• Test Security: Verify the host's security measures with the provided filesystem_browser.php script.
• Restrict _config.php: Remove world-writable permissions from _config.php after installation.

• HTML Filtering: Configurable levels of filtering prevent malicious script injection.
• Content Security Policy (CSP): Restricts the sources from which scripts and other resources can be loaded.
• Input Sanitization: Data is sanitized before being processed to prevent malicious code execution.
• Output Encoding: Data displayed to users is properly encoded to prevent interpretation as active code.

• DODGY_GET_HACK: Suspicious URLs with potentially harmful characters.
• EVIL_POSTED_FORM_HACK: Possible CSRF attempts via malicious form submissions.
• SCRIPT_UPLOAD_HACK: Attempts to upload PHP scripts, potentially malicious.
• DOWNLOAD_PRIVATE_URL_HACK/TRY_TO_DOWNLOAD_SCRIPT: Attempts to download sensitive files.
• BRUTEFORCE_LOGIN_HACK: Repeated failed login attempts.
• SQL_INJECTION_HACK: Attempts to exploit SQL queries for data extraction.

• Avoid FTP: Use secure alternatives like SFTP or SSH for file transfer.
• Secure Email: Enable SSL for IMAP and POP3 email protocols.
• Strong Passwords: Use unique and complex passwords for different services.
• Secure Computers: Keep your own devices patched and secure.
• Maintenance Password: Remove the maintenance password from _config.php when not in use.

• Visual representation of password quality and enforcement of complexity rules.
• Password expiry and prevention of re-use.
• Secure password hashing, even if the database is compromised.
• Temporary passwords for staff setup.

• Two-factor authentication via IP address approval.
• IP address banning, including wildcard banning.
• Session locking to IP addresses.
• Configurable session expiry times.
• Ability to prevent privileged actions from auto-logged in sessions.
• Optional member approval process.

• Comprehensive audit logging of administrative actions.
• Logging of user actions and IP address history.
• Tools to analyze audit logs.
• Failed login logging.
• Hack attack detection, logging, and banning.
• Email notifications for changes to user credentials.

• Protection against CSRF attacks.
• Click-jacking prevention via CSP implementation.
• Secure coding standards and scanning techniques.
• Configurable HTML filtering to prevent XSS attacks.
• Secure code modularization standards.

• Granular privileges and access permissions.
• Content submission validation process.
• Rootkit detection system.
• Spam prevention systems.
• Web application firewall rules.
• Moderation systems.

• MySQL timeout setting: For MySQL 5.7+, set a query timeout to prevent searches from locking up your database. Composr automatically sets this, but you can configure it manually if needed.
• Use InnoDB tables: Switching to InnoDB tables in MySQL can prevent slow queries from affecting other users on your website. Note that InnoDB is not officially supported by Composr yet.
• Enable the fast custom index: As mentioned earlier, the fast custom index is optimized for handling large datasets and filtered searches, potentially leading to significant speed improvements.