v11 alpha may be coming to bleeding edge releases soon

I am strongly considering the possibility of beginning to release v11 alpha as bleeding edge releases on the Composr site / downloads page. I have several reasons for doing so:

• This will allow those with less git experience to still test v11.
• This will allow the public to test the upgrader as we progress through each alpha version.
• Despite my recommendations against running v11 on a production site at this time, people already have v11 sites in production (including myself). And I will not stop anyone from doing so. In fact, these users will serve a critical purpose in the v11 development process because they can report production-level bugs and bugs with the upgrader.
• v11 has been in alpha longer than any Composr / ocPortal version ever made. While it will remain in alpha because I'm still implementing planned features, it will be good to get it into the standard Composr release cycle process.
• I want version 10.1 to disappear from the downloads page; it has been discontinued, and no one should be using it. But we can't simply remove it because that will disrupt the upgrade / release process. Releasing v11 alpha will take over the bleeding edge section of the downloads page and hide 10.1.
• This will enable better testing of the install / uninstall process of non-bundled addons.
• The installer, make release, and upgrader components in v11 are functional (with a few exceptions mainly pertaining to one's web environment). The only thing that doesn't work is upgrading from v10 to v11 (and we will strongly advise against doing this as long as v11 is in alpha), but upgrading between v11 patches works.

It may be a while before this happens, possibly a month or two, as I must perform some housekeeping mainly with the bug tracker first. Once 11.alpha1 is released, my goal is to have a new alpha out 1-2 times each month.

Note that this is the first time to my knowledge that we would be sending an alpha version through the official release cycle. Things can, and probably will, go wrong, especially at first. That's why we do these things: to test and fix what is broken.

Hopefully with v11 alpha in the release cycle, this will promote even more users to hop on board testing. And those with production v11 sites already can divert away from git and use a build instead, which is far more secure than running Composr on production from git.

Please let me know if you have any comments, suggestions, or questions about this in this topic.

Note that this is not a promise; I have not officially decided on doing this yet, but I am strongly considering it.

I think doing this would be of better benefit as well. Since I have two running locally one on IIS and the Other under Apache2 however having traffic and seeing what goes on live doesn't help much when trying to catch certain things to offer suggestions or bug notices.

Makes sense, I haven't bothered much with v11 as I was waiting for the Beta but packaged Alpha's we can update as normal would be welcome if this will eventually get us to the first stable build without anything major breaking as I too would like to run this live.

Adam said

Makes sense, I haven't bothered much with v11 as I was waiting for the Beta but packaged Alpha's we can update as normal would be welcome if this will eventually get us to the first stable build without anything major breaking as I too would like to run this live.

From “Post #9,555”, 7th January 2024, 9:24 pm

The drawback with alpha is that there is no guarantee things wouldn't majorly break. In alpha stage, API changes are still being made as necessary (e.g. changes to functions, database schema, etc).

When something reaches beta, that usually means "we're done messing around with the functions and schema (unless absolutely necessary), but we don't guarantee we fixed all the bugs yet". So beta is considered more stable than alpha, though still unstable by production standards.

I think however this would lead to a more stable release in the end though because there would have been more eyes / people testing v11 up to the first stable version. So there is a pro to it.

As per the feedback of the community, you overwhelmingly would like to see version 11 alpha hit bleeding edge release.

I have started the process of making this happen. Again, it could be a couple months before v11 alpha is released as bleeding edge.

These are the main chores that need to be done:

• Addon / module / block / theme guards need to be implemented so site admins don't accidentally install v10 addons on a v11 site and vice versa.
  • This is already in place for v11. I'll be working on this for v10 in a couple days, and a new patch of v10 will be released (10.0.45) containing this change.
• The Composr site is being prepped for the separation of addons. Luckily, not much needs to be done. I just need to clarify on the menu and pages which addons are for v10 and which are for v11.
• I need to ensure that v10 and v11 won't conflict with each other regarding the tracker. When releases are made, the make release tool will update referenced tracker issues accordingly. But a few tracker issues apply to both v10 and v11 which could cause some issues.
• v11 docs also need to be added to the site and separated from the v10 docs.
• The developer email which the software uses to email errors automatically needs to be created and activated.
• v11 needs to go through a full (or almost full) unit test on both Windows and Linux. This will probably take the longest of all the chores. Of course, not everything will get fixed. But as much as possible should be fixed before the bleeding edge release.

Thanks for your work, Chris and Patrick, and all involved. I've supported this project for a long time, even though I don't have any projects (yet) that use it. I saw the genius in this CMS years ago, and now it's really starting to show its power. Thanks again!

Status update:

v11 alpha1 preparations are going smooth. I just completed the primary unit test suite on Windows with PHP 7.4. I still have the secondary unit test suite to run + code quality checker. Then I need to run all unit tests again on Linux (with PHP 8.3). And while that's happening, I'll be running security penetration testing.

We are currently on track for my planned March 2 target date for v11 alpha1 to hit bleeding edge. Again, this is not a promise as anything can happen.

Status update:

Unfortunately, alpha1 will not be ready by the given target dates. I have been delayed by client work and other technical issues the past 2 weeks. However, progress is coming along. The main project at this moment is fixing a bunch of PHP 8 related issues in v11.

Current progress:

Unit test pass-through 1 on Windows 11 with PHP 7.4 (includes underscore tests)* - Complete
Unit test pass-through 2 on Windows 11 with PHP 7.4 (quick)* - Complete
Unit test pass-through 1 on AlmaLinux 8 with PHP 8.3 (includes underscore tests)* - In progress
Unit test pass-through 2 on AlmaLinux 8 with PHP 8.3 (quick)* - Pending
Security penetration test on Windows 11 with PHP 7.4 - Pending (might be deferred to a later alpha or to beta)
Set-up of basic v11 site - Pending
Basic stress test - Pending (I may defer this to beta)
Release testing - Pending

*Non-critical tests (such as code quality checker) are being deferred to later alphas to speed up the release process.

I'm hoping to get alpha1 ready within the month. But I cannot make any promises on that. The new target date given my circumstances is March 31.

Status update:

We are closer to v11 alpha1.

* composr.app is up, which will be the new site for v11. The v11 codebase now uses this site as the default brand base URL.

* Errors get reported to composr.app via an API instead of e-mails now (errors are encrypted with a public/private key pair rotated by major.minor version combo to preserve privacy and security).

* General releases now seem to work, including upgrading between v11 releases.

Still need to test addon updating / publishing. After that, it might be a go for v11 alpha1.

It is out!

Does the "Happy Dance"  

Easter eggs and v11, both will be consumed!

I wonder if this will make you technically fat or high cholesterol and over-excited?

Probably have the first two covered already, but over-excited is a definite.

Just to cover my lil rat rear… I like throwing a little humor into the mix. Wait! A lot of humor, it adds spice to the equation. Just don't pull my tail!

v11 alpha1 has a couple big bugs with the system scheduler… if you add a download, reorganise uploads is enabled, and download indexing is enabled (all conditions true by default), then download indexing fails because it's trying to grab a file that doesn't exist. Furthermore, the schedule hooks page throws an out of memory error if the task queue gets backed up (easy to do because of dispatch notifications). And task queue itself runs out of memory trying to process them all.

v11 alpha2 will be quickly released in a few days to remedy these bugs. I'm holding off a little in case I find more big issues.

* Scheduled task hooks will not return list of tasks queued if over 300 to prevent memory errors.
* Cron will not try to process all tasks at once. Instead, it will process tasks one at a time until either 10 seconds have elapsed or 3,900 database queries were made. Then it will stop and wait for the next Cron execution.
* Warnings have been added on the system scheduler hooks page to let you know if the scheduler is not running due to a pending upgrade, or if any hooks appear to have locked.
* Download indexing has been fixed. It will check for the correct file now *after* reorganise uploads runs, and it will exit if for some reason the file does not exist instead of trying to process a file that doesn't exist.

Those running git can pull the latest commits to get these changes.

I said a few days but it ended up being over 2 weeks. Nonetheless alpha2 is out.

I forgot to mention, my upcoming plans are as follows:

* I will be working on 10.0.48 for the next week or two. I'll be fixing reported bugs and implementing a change to the upgrader which will be necessary for upgrades from v10 to v11 to work (this will not be the only change necessary, but it will be one of probably a few).

* I will then switch back to v11 and work on alpha3. This version in particular, I will be running security penetration testing on and implementing fixes to tighten v11 security. I will also be doing API testing and fixing other areas I have not yet been able to fix or test.

* I will then start the process of testing v10 to v11 upgrades and figuring out what all needs to be done for this to work. This will result in a follow-up 10.0.49 patch release and a v11 beta1 release at roughly the same time. At this point, v11 will have entered beta status.

* Chris Graham will hopefully have joined me by this point, and the both of us will be hard at work progressing v11 to stable, which we hope to do so by July 2024. v10 will be put on hold during this time except if we need to push more patches so upgrades to v11 work. There will be multiple v11 beta releases during this process. They might be rapid (aka. we might be pushing a beta every couple weeks, sometimes quicker) since we're spending lots of time on v11 at once.

v10.0.48 is being postponed due to a bug I cannot fix at this time. I need to move back over to v11 work due to the tight deadlines to get it out.

So 10.0.48 will probably not come out until after 11 alpha3 now.

As a heads-up, a lot of changes (mostly behind the scenes) will occur between 11 alpha2 and 11 alpha3. Some extra considerations may need to be made if you're running a v11 site:

* The names of the fast custom index options have changed. So you will need to set these settings again as they will probably revert to defaults after upgrading to alpha3 (once released). The _fulltext_index tables however should continue to work.

* The format of errorlog.php has changed to include a log level. This will be parsed on the error log UI in the Admin Zone, and each entry will be coloured according to the log level. (Old) records without a log level will default to WARNING.

* A lot of changes behind the scenes are being made to the code to better support rebranding. I'm changing many hard-coded references to Composr or its sites to use generic terminology or get_brand_base_url() / brand_name() functions. Every file will still contain at minimum "Composr" at the top of the copyright comment. A few hard-coded Composr references which would be too detrimental or breaking to change will remain.

• This largely will not affect actual operation of the software. However, a few config options which had the word composr in them might be renamed (causing them to revert to default when upgrading to alpha3). And I'm still debating whether or not to rename a few non-bundled addons which contain composr in the name (especially composr_homesite, composr_homesite_support_credits, and composr_release_build).

Once I get the upgrader for v10 to v11 working, it will properly transfer over the values of said config options when upgrading a v10 site to v11.