Skip to content

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

@bimimicah

Description

@bimimicah

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementSomething that we currently don't do, but could. AKA feature requestprocess-itemNot really a coding issue, but a TODO nonetheless

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions