Core Update Schedule frequency

[burt]

The latest 1.1.0.7 release in July 2026 was larger than normal as the previous release was September 2025.

That schedule is a lot longer than usual, due to some external and internal factors - unfortunately it was the best I could manage with my available time and effort. The bottleneck was not ideas, features, or willingness to continue improving Phoenix - it was development capacity.

Anyway...

Releases (up to & including 1.1.0.6) were made about every 6 weeks so were usually much smaller.

Based on a recent thread about "shopowners never updating" (though I am not sure that's entirely fair/correct, it's more or less an anecdote from a personal experience in that thread)...should updates;

a/ be more regular (as they used to be, roughly monthly-ish)
or
b/ be less frequent, perhaps twice a year, with larger collections of changes?
or
c/ something else. If so, what's your thinking?

Thanks in advance for any thoughts.

--

When I mentioned "development capacity", I'm not referring only to core code. During the gap between 1.1.0.6 and 1.1.0.7 there was a considerable amount of work outside the core release itself - supporting the community, maintaining and developing addons, dealing with changes in the core team, creating the new `default` template, launching the new website, introducing the Co-op, developing Product Anywhere, experimenting with ideas that were ultimately shelved, and handling the day-to-day forum activity. All of that draws from the same finite pool of time and effort.

[Kofod95]

Thanks in advance for any thoughts.

This is something I have tried thinking about a few times.

The small updates have obvious advantanges. At the same time, it's easy to fall quite a lot behind rather quickly.
To me, as a hobbyist, I want to keep my own add-ons updated, but I don't have time every month, and with each new update, I'm just falling further and further behind.
I have sometimes heard people using WordPress complaining about the frequent updates, seeing them as an annoyance rather than a plus.

However, bigger updates might be more prune to errors (in releases and when updates are performed). Also, more things will likely break at once, making the update itself a bigger task than now.

I have earlier expressed a wish for x.x.x.x to be the references (in lack of a better word). If the version checker could graduate (fx: "there is a new minor version available"), this could maybe help store owners not feeling behind constantly, while still allowing small frequent updates?

//Daniel

[14Steve14]

I am sort of torn between occasional large updates or more frequent smaller ones. I stopped updating my site and the next update as a big one with many major changes and I just didn't have time. The update took very little time on my test site, but after it was the checking and updating of the bits that broke. I stopped updating and to be honest the site has been working great for the last two+ years. Why update when its working.

My problem now is that my hosts are supposed to be dropping early versions of PHP and without a lot of work the site will only work on php8.0 and no higher without lots of testing and fixes so its back to creating a whole new site on the latest version. Its easier to do it once properly and then see what features get added in an update, or what current feature is improved.

Time and cost wise for me its easier to sit and do one big update rather than lots of smaller ones, but I do like the idea of smaller ones until something goes wrong. I suppose this is saying that there is no real right or wrong way of updating, or a correct way of offering the updates.

[burt]

TY guys for your thoughts. They help.

I have split the post to it's own thread so it's easier to read (as in the other
thread there might have been unrelated technical stuff re 1.1.0.7).

Please, if anyone else has thoughts on Core update release frequency, I'd be appreciative.
No right or wrong answer. I just need more data to come to a conclusion.

[ecartz]

A side issue here is that if there were less core, there would be less to update and updates could be smaller even if less frequent. I.e. if things like testimonials and advertising were outside core, their updates wouldn't be part of core. As is merchants find themselves updating features that they don't use as they're part of core.

Smaller updates are easier to apply. Part of the problem here is balancing the fun stuff (new code) against the boring chores (testing and packaging). Updates don't get large from insufficient dev time. They get large because more time is spent coding than packaging. If the balance leans toward coding over packaging (counting testing as part of the packaging) the update gets large.

I don't have a good solution for this. When I was doing the updates, I made tools to automate various pieces. But we've never gone through and automated the testing portion. Perhaps a new repository that automates some of that, importing from core as needed.

To get back to the original question: I think size is more important than frequency. I would try to keep the size down more than I would try to keep the frequency up. Small quarterly updates would be fine. Large monthly updates can be problematic.

Note that the people who don't update won't update regardless of schedule. I don't think the project would work with a biennial (every two years) schedule. But some store owners would still resent that as too frequent and skip updates. If there were less core, quarterly updates would likely be a reasonable compromise.

[burt]

I have earlier expressed a wish for x.x.x.x to be the references (in lack of a better word). If the version checker could graduate (fx: "there is a new minor version available"), this could maybe help store owners not feeling behind constantly, while still allowing small frequent updates?

How it works at the moment;

Release is made (eg the recent 1.1.0.7). That becomes "master" at Github.
A branch is then made 1.1.0.8 - and this is where development goes.

At some point, that branch merges to master, release is made (1.1.0.8)
Cut a new branch 1.1.0.9

In other words, it is x.x.x.Y that is usually updated.

--

Whereas I think you are saying;

Run TWO branches after a release.
x.x.Y.x <--- for all updates (bugfixes/security included)
x.x.y.Y <--- for important stuff like bugfix/security only

So someone on (say);
1.1.1.0

The next main release would be;
1.1.2.0

But in the meantime, a
1.1.1.1
1.1.1.2
etc might be released which may have very few changes (eg a bugfix).

--

Am I understanding correctly?

Basically, move the versioning from the 4th spot (a.b.c.D) to the 3rd spot (a.b.C.d), and leave the 4th spot for bugfixes/security.

[raiwa]

I agree. The most important I think is to separate bug and security fixes from introducing new features updates.
And the second digit xYxx for mayor steps like bootstrap version updates.

[burt]

Open to all, to think about;

When a bug is discovered, what are the exact step-by-step actions required to fix it, test it, and release it across two separate branches (stable vs. development) compared to just one?

[Dan Cole]

@burt Gary I haven't bothered to comment on this thread since it seems to me that if we have upgrade software, like what @BrockleyJohn is developing, then releasing any PhoenixCart Core Updates and Bug Fixes should be left to the developers to handle at a frequency and time that is convenient for them. I think it is important to support the development of upgrading software that makes updating easy so we can bring the community together rather than it being fragmented, as seems to be the case now, with all the various versions that seem to be in use. Just my nickels worth.

Dan

[burt]

bring the community together rather than it being fragmented, as seems to be the case now, with all the various versions that seem to be in use.

Well, there is a nuclear option... EOL (End Of Life) all versions prior to "a version, to be decided".

If shopowner is on a version that is EOL, they have chosen to be on their own and that's OK. Open source relies on shared progress. If a user chooses to keep their store frozen in the past, they naturally lose the ability to shape the future direction of the software.

Perhaps that's a way to free up some capacity?