versioning of license list
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
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
We only have changed the major number when there was a major change - addingYes, I would say that's pretty normal for software projects. Incrementing the
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?
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
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" <swinslow@...> writes:
So I'd be inclined to stick with the current M.N format for now, and+1 -- semver is not really useful here, and 3.20 looks perfectly fine
keep incrementing 3.x unless and until we hit a significant enough
change to bump it to 4.0.
in the eyes of developers (and probably beyond.)
All best,
--
Bastien Guerry
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.)
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 natureof the license repo. We've selected major number to indicate a format(which one could argue is the semantic element that count) and a minornumber for release number that includes additions and minor technicalcorrections only. All the 3.x releases are basically compatible froma format point of view, but have different content. I see no valueother than confusing from introducing a 'tiny' rev to the processsince there's already a quarterly release cadence.Warner