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.