Re: versioning of license list

Steve Winslow

Thanks all!

One note just for consideration here: the version numbering for the License List has at least a syntactic meaning also within the spec itself, for SPDX documents:  see

That defines it as a "Major.Minor" format. That could be changed for a future release of the SPDX spec of course, but I expect that would be a breaking change if it went to something like semver.

So I'd be inclined to stick with the current M.N format for now, and keep incrementing 3.x unless and until we hit a significant enough change to bump it to 4.0.

At four releases a year, that should give us *does some quick math* roughly another 20 years before we hit a Y2K issue with the minor version number, so I think we should be fine for now  :)


On Thu, Apr 28, 2022 at 5:02 PM Sebastian Crane <seabass-labrax@...> wrote:
Dear Jilayne,

> We only have changed the major number when there was a major change - adding
> license expression operators for 2.0; changing to XML format and major
> change to GNU identifiers or 3.0. I don't really foresee a major change of
> that nature on the horizon (good!). This would mean we just keeping going
> with 3.y - is that normal?

Yes, I would say that's pretty normal for software projects. Incrementing the
major version usually indicates that upgrading to that version would break
something for existing users that rely on the data, so 3.16 to 3.17 would be
'correct' for this release (which shouldn't break anything!)

If we were going full 'semantic versioning' (formalised at
), however, we'd also have a 'patch level' version for releases that only fix
existing licenses and don't add any new ones: 3.17.0 would become 3.17.1 if
there were no new licenses or exceptions added between those releases.

I don't have a strong desire to change it though, rest assured :)

Best wishes,


Join { to automatically receive all group messages.