Core Update Schedule frequency

[burt]

Re a.b.C.d and a.b.c.D

Question, open to all;

If every bug fix, security patch, and minor feature now requires double the commits, double the testing environments, and multiple release packages, how does that impact the total development capacity available for the project?

[PiLLaO]

Re a.b.C.d and a.b.c.D

Question, open to all;

If every bug fix, security patch, and minor feature now requires double the commits, double the testing environments, and multiple release packages, how does that impact the total development capacity available for the project?

I'm really lost in this thread.

The translation is awkward, and I'm getting lost amidst all the text and technical jargon.

I'm trying to read through the whole thread anyway, but I'm afraid I can't contribute much in this case.

[burt]

I'm really lost in this thread.

The translation is awkward, and I'm getting lost amidst all the text and technical jargon.

I'm trying to read through the whole thread anyway, but I'm afraid I can't contribute much in this case.

By my understanding, some readers are advocating for Phoenix to change from this;

1.1.0.8
↓
1.1.0.9
↓
1.1.0.10

to (eg) this:

1.1.1.0 → 1.1.1.1 → 1.1.1.2
↓
1.1.2.0 → 1.1.2.1
↓
1.1.3.0 → 1.1.3.1 → 1.1.3.2
↓
1.1.4.0

Where the ones in bold are the current live versions (per release). So anyone on (eg) 1.1.1.0 can get security fixes without having to jump to 1.1.2.0. For example. An incredible amount of extra work, when development capacity is already maxed out.

[PiLLaO]

For me, that I'm not a expert, since I can make changes without modify core using hooks and override, I think it's better option like actual.

Perhaps releasing smaller versions with fewer changes (but more frequently) would be a better option (for more people) than a later release with more changes.

[azpro]

Where the ones in bold are the current live versions (per release). So anyone on (eg) 1.1.1.0 can get security fixes without having to jump to 1.1.2.0. For example. An incredible amount of extra work, when development capacity is already maxed out.

Quick response - Maybe I do not understand correctly.

I believe Phoenix has limited resources in development time - so I would prefer to max this development time and bring Phoenix further - and not to cater users who are behind updating.

It's free soft and not all users get what they want. Especially the users who take the risk not to update .. No offence intended - I know how hard it is keeping up-to-date but we/Phoenix need to make choices.

[burt]

Another question, open to all;

If we pull features out of the core to make it more lean, who decouples the code, and who commits to maintaining those individual addons when PHP versions or core change?

If the core team has to do it, we haven't actually reduced the workload - we've just fragmented it. If the community has to do it, who is stepping up to own them?

[Kofod95]

By my understanding, some readers are advocating for Phoenix to change from this;

I will try to elaborate, as I haven't been too clear. I'm not advocating for multiple "live" or "stable" releases. My thinking was more like:
a.b.c.D - minor update whenever needed for bugfixes or security. Only on current "C" version.
a.b.C.d - once or twice a year to gather enough to make it attractive to update, but not so much that the entire cart is recoded.

One a new "C" is out, the old one is EOD (end of development - I don't know if that phrase exists), and with the next "C" it's (officially) EOL (meaning no "official" support - maybe even something with add-ons)

//Daniel

[burt]

It makes sense. Under this plan (if I'm understanding correctly), there still has to run two separate live code branches on GitHub at the exact same time:

1. The "Now" branch (1.1.1.0 -> 1.1.1.1 -> 1.1.1.2), where there is tiny, isolated bug fixes.

2. The "Next" branch (1.1.2.0), where there is actively writing new features for the next big release.

Every time a bug is found, it has to be fixed in the Now branch, tested, release a new zip, released etc
And then merge that fix forward into the Next branch without affecting whatever new code is in place.

On release of "Next", that becomes the "Now" branch, then the process repeats.

Is my understanding correct?

This workflow means running two active branches simultaneously. Every bug fix requires coding it in "Now", testing it, packaging and releasing a new zip/update, and then forward-merging it into "Next" while manually resolving any code conflicts with the new features.

You can prob see that this is, more or less, a doubling of the admin and development workload. If we were to move to a structured system like this, how do we solve the development capacity problem?

[ecartz]

I think Daniel is just advocating semantic versioning.

If you release a change that is not backward compatible, you make it a a.b.C.0. If you release a.b.c.D then it should only have bugfixes (including security fixes) in it compared to a.b.c.0.

The problems with this are essentially that it slows down actual development. Because you have a "not yet live" version with new development. And of course, the "not yet live" version has to get the get the same bug fixes as the live version. While not having anyone actually using it. Which is the same problem as two live/stable releases only with less assistance.

My approach was essentially the reverse. To close off development and do only bug fixes at the end of a release cycle. Until no one mentioned bugs anymore. And then release a .0 version that was just the most recent version with a new version number. And then release a .1 version as there are some bugs that don't get found until the .0 release.

In terms of fragmenting the release with a slimmer core, I continue to think that's helpful. Because the more we can split things off from core, the less their updates impact core. Now, if there's a testimonial or advertising update, core needs to update. If they were out of core, core doesn't. Their release could happen entirely out of synch with core.

The only synchronization that would be necessary would be to update the add-on features when the part of core on which they're built changes. Which is hopefully seldom.

[burt]

This is about a more than just "code", right - let's broaden the conversation. This whole ecosystem, both internal (site, forum, addons etc) and external (github etc) needs to be looked after.

Finite hours makes it difficult to find the time that is needed to look after everything.
I do as much as I can, in the time I have outside the day-job, to keep Phoenix burning, but I am at max now.

--

Cutting down on one bit of the ecosystem, might give more time to another bit.

There are answers, but all the answers depend on others stepping up to help.
Getting others to step up is hard.