It's odd to throw that into a patch release.
-
It's odd to throw that into a patch release. I guess we'll find out if I did it correctly.
I mean, where else should they show that warning? It's also posted in the forum. They also edited the documentation page.
Maybe you're more into mailing list or the like? I'm genuine curious on what and how you expected getting this kind of information.
-
I mean, where else should they show that warning? It's also posted in the forum. They also edited the documentation page.
Maybe you're more into mailing list or the like? I'm genuine curious on what and how you expected getting this kind of information.
I expect in a patch release that nothing has changed and I can blindly update getting minor bug fixes and security fixes. In a minor release I expect to review the changes for configuration changes or any minor UI changes. For a major release I expect to read docs on how to upgrade and prepare backups and downtime.
-
I expect in a patch release that nothing has changed and I can blindly update getting minor bug fixes and security fixes. In a minor release I expect to review the changes for configuration changes or any minor UI changes. For a major release I expect to read docs on how to upgrade and prepare backups and downtime.
Exactly. It has nothing to do with where they post it, but what their version numbers communicate. I should be able to blindly apply patch releases, and this breaks that.
I'm even okay with a minor release here. It was never advertised to work that way so removing it technically isn't a breaking change, but there is a known breakage here. I'm much more likely to read minor release notes than patch release notes, so I would likely see this warning if it was a minor release.
-
It's odd to throw that into a patch release. I guess we'll find out if I did it correctly.
I mean, it's patching a security issue caused by trusting headers it shouldn't, so I don't think they should wait for a big number release.
-
Exactly. It has nothing to do with where they post it, but what their version numbers communicate. I should be able to blindly apply patch releases, and this breaks that.
I'm even okay with a minor release here. It was never advertised to work that way so removing it technically isn't a breaking change, but there is a known breakage here. I'm much more likely to read minor release notes than patch release notes, so I would likely see this warning if it was a minor release.
It's patching an undocumented security bug. That's perfectly fine in a patch release.
-
I mean, it's patching a security issue caused by trusting headers it shouldn't, so I don't think they should wait for a big number release.
Why wait? Just release it as a big number release. The version number doesn't define the size or cadence of a release, it just says whether there's a breaking change.
-
I expect in a patch release that nothing has changed and I can blindly update getting minor bug fixes and security fixes. In a minor release I expect to review the changes for configuration changes or any minor UI changes. For a major release I expect to read docs on how to upgrade and prepare backups and downtime.
Ohhh thanks for the clarification ! As you guest I'm not into dev/programming so I wasn't aware of this kind of detail !
Thank you
-
Ohhh thanks for the clarification ! As you guest I'm not into dev/programming so I wasn't aware of this kind of detail !
Thank you
Yeah, it's really nice when done properly. I have my images pinned to minor releases (they can sometimes break backwards compatibility on accident), so I expect upgrades to newer patch versions to mostly be safe. Mistakes happen, but if 95% of my patch upgrades work w/o intervention, I'll probably enable automatic updates.
As a refresher for others, a semantic version looks like this: X.Y.Z:
- X - bump when breaking backwards compatibility
- Y - bump for new features
- Z - bump for bug fixes
You can always bump a "higher" version whenever you like (e.g. 2.0 may not break compatibility w/ 1.0), but never bump a lower version (i.e. bumping Z should never break backwards compatibility). A version bump generally indicates how much I should pay attention to the release notes.
-
Why wait? Just release it as a big number release. The version number doesn't define the size or cadence of a release, it just says whether there's a breaking change.
At least in my org we use semantic versioning ( Major.Minor.patch) where patch must either be a new feature, a fix, or something that is backwards compatible
Minor can be breaking
Major is basically something you're proud of lol
-
At least in my org we use semantic versioning ( Major.Minor.patch) where patch must either be a new feature, a fix, or something that is backwards compatible
Minor can be breaking
Major is basically something you're proud of lol
That's not semantic versioning...
-
That's not semantic versioning...
Guess my org fucked it up ¯\(ツ)/¯
-
System shared this topic on