ProcessWire 3.0.275 – Core updates

[ryan]

This week we have ProcessWire 3.0.275 on the dev branch. Relative to 3.0.274, this contains more than 90 commits, many related to older issue fixes from our GitHub issues repo. Also released this week is ProcessWire 3.0.260 on the main/master branch. When there is anything potentially security related, I back port those updates from the dev branch to the main/master branch, and bump the master branch version. This maximizes the security and stability of both branches at the same time, so it's become part of the regular work flow these last few months. More next week. Thanks for reading and have a great weekend! 

[adrian]

Thanks for all the amazing fixes Ryan!

I am curious though about the master version numbers - we've obviously already had a 3.0.260 (https://github.com/processwire/processwire/commit/ddd4ada40197cc45b1fd94a33dd2feea74b9562e) so isn't that potentially problematic that two PW installs with the same version number are completely different? Maybe there are limited practical issues with this, but I feel like it would be great to come up with a better solution moving forward, especially if backporting fixes to master becomes more commonplace.

[ryan]

The version numbers on the dev branch aren't tagged, whereas the version numbers on main/master are. Also the dev branch versions have a "dev" suffix where as master branch versions don't. I'm not sure of a better way to do it but always open to ideas 

[AndZyk]

Maybe it would be time for ProcessWire 3.1 after eleven years. 😁

[adrian]

@ryan - I think this is a real problem.

Part of the problem is that "dev" is not actually part of the version number from $config->version. 

Imagine a 3rd party module that says it requires 3.0.260 because of a feature that was added in 3.0.260 dev. It will install in 3.0.260 master, but won't have what it needs to run. This could result in fatal errors.

Another possibility is that someone could actually end up going backwards when "upgrading" if they are coming from a dev version that has features that the new master doesn't have.

It will also complicate bug reports.

I think backports should add a fourth part to the version number, eg, instead of master 3.0.260, you'd version it 3.0.255.1 - so it's a new version of the current master. Basically, it's 3.0.255 plus some fixes.

 

[DV-JF]

I maybe figuered out a small bug: Just tried to upgrade from 3.0.248 to 3.0.260 via ProcessWireUpgrade 0.1.1 but that doesn't seem to work: I’ve tried it twice, but instead of upgrading, the old version 3.0.248 was displayed on both occasions in the footer.

Manual installation via FTP upload works without any problems.

I find the version naming schema just as problematic as @adrian does. At first glance, I can’t tell the difference between the Dev version 3.0.260 and the Master version 3.0.260 – or am I mistaken?

 

[sleepycron]

I'm with adrian on this one. I only ever update from master, and if a module said it needs 3.0.260 I honestly wouldn't know which 3.0.260 it means. Something like 3.0.255.1 would make it obvious at a glance that it's the old master plus fixes.

[ErikMH]

I’ve had to deal with this type of issue in the past, and while there’s really no perfect answer, the closest I’ve come is to equate sequences only and always at sublevel 1. The dev channel keeps iterating, but every time main is brought up to parity, it signals a new sublevel 1 sequence. This makes, obviously, for a more frequent sublevel 1 cadence, but — let’s face it! — that’s really not a problem currently with ProcessWire! 🤣

Dependencies, then, are keyed as “requires 3.1,” requires “3.2,” etc., and never at sublevel 2.

Here it is visually, with `==` signifying identical releases, and `<--` showing security and other essential patches moved from Dev to Main.

Main             Dev
3.0.259    <--   3.0.259
3.1         ==   3.1
                 3.1.001
3.1.002    <--   3.1.002
3.1.003    <--   3.1.003
3.2         ==   3.2

3.1.001 was new features or less-important fixes only, so that numbering is skipped in Main. But we *do* set 3.1.002 with the name that shows it bears the same security patches as in Dev’s 3.1.002.

tl;dr:

• X.       major release, equivalent on both channels
• X.y     minor release, equivalent on both channels: dependencies resolve here!
• X.y.z  subrelease, equivalent only in terms of security, dev channel or both channels, as appropriate

Edited 7 hours ago by ErikMH
tl;dr

[eelkenet]

One of the main reasons I'd love to have everything we have now bundled into a ProcessWire 4.0 (or 3.1), is that from that moment on we could introduce Semantic Versioning (SemVer) for ProcessWire releases.
Being (and staying) future-proof is clearly a goal of this project, and I think it would help a lot if the versioning becomes more consistent and predictable. 

That would also require some sort of public roadmap. (And maybe some sort of foundation to run this project...?)