1. Spdx-Legal
  2. Topics

versioning of license list

J Lovejoy
 

Hi all,

As I was adding milestones to the Github repo for the next couple releases, I wondered... do we just keep going with 3.18, 3.19, 3.20... (and 3.20 looks a lot like 3.2, but I guess that was also the case with 3.10 and it wasn't an issue)?

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?

Interesting to hear thoughts on this from more software-versioning-traditions savvy people :)

Jilayne

Alan Tse
 

I don’t think it’s an issue. To developers, 3.20 is normal and won’t be confused as 3.2.

 

I would advocate moving to semantic versioning where it uses a triplet (e.g. 3.20.0) and each part of the triplet has a meaning when it’s incremented. It may not matter since SPDX doesn’t release frequently enough to do “fix” only releases which would be 3.20.1, but at least it signals to downstream users that if the major version changes (e.g., 4.0.0) that the API may have broken.

 

Another benefit of semantic versioning is you can adopt tools like semantic release to automatically make the next version with a changelog.

 

 

From: <Spdx-legal@...> on behalf of J Lovejoy <opensource@...>
Date: Thursday, April 28, 2022 at 10:55 AM
To: "Spdx-legal@..." <Spdx-legal@...>
Subject: versioning of license list

 

CAUTION: This email originated from outside of Western Digital. Do not click on links or open attachments unless you recognize the sender and know that the content is safe.

 

Hi all,

As I was adding milestones to the Github repo for the next couple releases, I wondered... do we just keep going with 3.18, 3.19, 3.20... (and 3.20 looks a lot like 3.2, but I guess that was also the case with 3.10 and it wasn't an issue)?

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?

Interesting to hear thoughts on this from more software-versioning-traditions savvy people :)

Jilayne
Sebastian Crane
 

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 https://semver.org/
), 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,

Sebastian
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 https://spdx.github.io/spdx-spec/document-creation-information/#67-license-list-version-field

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  :)

Steve

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 https://semver.org/
), 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,

Sebastian
Bastien
 

Hi Steve,

"Steve Winslow" <swinslow@...> writes:

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.
+1 -- semver is not really useful here, and 3.20 looks perfectly fine
in the eyes of developers (and probably beyond.)

All best,

--
Bastien Guerry
Warner Losh
 



On Fri, Apr 29, 2022 at 3:28 AM Bastien <bastien.guerry@...> wrote:
Hi Steve,

"Steve Winslow" <swinslow@...> writes:

> 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.

+1 -- semver is not really useful here, and 3.20 looks perfectly fine
in the eyes of developers (and probably beyond.)

I agree here. I think semvar's notions are an imperfect fit for the nature
of the license repo. We've selected major number to indicate a format
(which one could argue is the semantic element that count) and a minor
number for release number that includes additions and minor technical
corrections only. All the 3.x releases are basically compatible from
a format point of view, but have different content. I see no value
other than confusing from introducing a 'tiny' rev to the process
since there's already a quarterly release cadence.

Warner 
J Lovejoy
 

Thanks all for the confirmation to keep on keepin’ on with our current mode, then!

J.

On Apr 29, 2022, at 7:25 AM, Warner Losh <imp@...> wrote:



On Fri, Apr 29, 2022 at 3:28 AM Bastien <bastien.guerry@...> wrote:
Hi Steve,

"Steve Winslow" <swinslow@...> writes:

> 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.

+1 -- semver is not really useful here, and 3.20 looks perfectly fine
in the eyes of developers (and probably beyond.)

I agree here. I think semvar's notions are an imperfect fit for the nature
of the license repo. We've selected major number to indicate a format
(which one could argue is the semantic element that count) and a minor
number for release number that includes additions and minor technical
corrections only. All the 3.x releases are basically compatible from
a format point of view, but have different content. I see no value
other than confusing from introducing a 'tiny' rev to the process
since there's already a quarterly release cadence.

Warner 

1 - 7 of 7