Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider switching to Semantic Versioning (semver) and more frequent Revision (bugfix-only) releases #63

Open
bimimicah opened this issue Mar 11, 2025 · 1 comment
Labels
enhancement Something that we currently don't do, but could. AKA feature request process-item Not really a coding issue, but a TODO nonetheless

Comments

@bimimicah
Copy link
Collaborator

bimimicah commented Mar 11, 2025

TL;DR: old system is based on Apache HTTPd's breaking changes, not semver. Maybe we should switch to semver?
The logical conclusion of that is Revision (1.0.x) releases should exist (these are "non-breaking bugfix-only releases"), and thus bug fixes should not wait to be wrapped up with extra features before release. (the old model relied on distro maintainers cherry picking fixes from master) That's probably a good change.

you may want to consider releasing it as v3.4.0 or v4.0.0 because the following (in v3.3.3) is a change to the API (and the change I am trying to consume) and a higher version increment can help bring that to attention:

Added the "GroupExternalAuthNCheck Off" directive to disable the check
for a previously authenticated user when using only the group
authorization module. If you use any user authentication module in the
same context, this may be undesirable. Thanks to Micah Andersen/BIMI.

Hmmm. Interesting suggestion; I'll have to think about that. The big reason many distros haven't moved beyond the last few versions (3.3.0, 3.3.1, 3.3.2) is because this is a relatively stable project with few major changes; mostly small fixes.
So a lot of times, historically, I think people haven't moved to a newer version until they needed to upgrade Apache httpd and needed a newer version of this to go with it.
There hasn't been a major breaking change to Apache in over a decade (version 2.4 introduced changes which were resolved by our v3.3.0), so some distros haven't bothered to look for an updated mod_authnz_external package since then (OpenMandriva and NetBSD are good examples).
For similar reasons, ever since the 3.x series started in 2006, we basically don't make breaking changes until Apache does.

That's one of the big reasons I haven't made the v.3.3.4 release yet (see #37). I have been worried because it has a pretty substantial addition (AUTHORIZE_ headers are added to the external processes' environment values, the first environment variable addition since CONTEXT was added in 2008) which could theoretically break applications that have been expecting a specific environment table size for the last 2 decades.... And now that I have that all in writing, I think I've made up my mind about #37, I'll definitely put it behind a flag.
Basically all of that to say, our versioning system so far has been basically "Apache httpd-based", or something like this:
Read this table from the bottom up, it makes more sense that way....

Major.Minor.Revision
  ^     ^      ^
  |     |      |
  |     |      ➥ Any other changes
  |     ➥ New Apache minor versions based on the same design (e.g. when 3.3 fixed minor issues to upgrade us to Apache 2.4)
  |     ➥ Internal (non-breaking) rewrites (e.g. when 3.2 switched to use APR under the hood)
  ➥ Complete rewrites of internal and external design (e.g. when 3.0/3.1 introduced the Apache authnz model)

If we switched to semver (Semantic Versioning), which seems to be the standard nowadays, then it would look like this:
Read this table from the top down, it makes more sense that way....

Major.Minor.Revision
  ^     ^      ^
  |     |      |
  |     |      ➥ Non-breaking _bug-fixes_ only (e.g. when 3.3.3 fixed the parenthesis grouping bug that was unlikely to ever trigger)
  |     ➥ Non-breaking new features (e.g. when 3.3.3 added the GroupExternalAuthNCheck directive/flag)
  |     ➥ Non-breaking internal changes (e.g. when 3.2 switched to use APR under the hood)
  ➥ Anything that breaks compatibility, including:
          Complete rewrites of internal and external design (e.g. when 3.0/3.1 introduced the Apache authnz model)
          New Apache minor versions based on the same design (e.g. when 3.3 upgraded to Apache 2.4 and removed AuthBasicAuthoritative and GroupExternalAuthoritative)

Essentially, if we switched to semver, then 3.3.4 would actually be 3.4.0 and if anyone (me, I guess) ever gets around to adding the features for #40 and #21, then those would be in 3.5.0 or later.

Originally posted by @bimimicah in carrvo/debian-libapache2-mod-authnz-external#1 (comment)

The logical conclusion of switching to semver is that Revision (1.0.x) releases should exist (the "non-breaking bugfix-only releases"), and thus bug fixes should not wait to be wrapped up with extra features before release. (the old model relied on distro maintainers cherry picking fixes from master) That's probably a good change.

@bimimicah bimimicah added enhancement Something that we currently don't do, but could. AKA feature request process-item Not really a coding issue, but a TODO nonetheless labels Mar 11, 2025
@bimimicah bimimicah changed the title Consider switching to Semantic Versioning (semver) and more frequent Revision (bugfix only) releases Consider switching to Semantic Versioning (semver) and more frequent Revision (bugfix-only) releases Mar 11, 2025
@bimimicah
Copy link
Collaborator Author

@phokz, if you have any thoughts on this, please let me know. Otherwise, we will probably switch to Semantic Versioning going forward.

@carrvo, thanks for the idea!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Something that we currently don't do, but could. AKA feature request process-item Not really a coding issue, but a TODO nonetheless
Projects
None yet
Development

No branches or pull requests

1 participant