📣 v2 finalization

[jkowalleck]

• keep test coverage at ~100% << it lowered during new implementations in prep for this release
• remove the v2 dev hint from README
• ... TO BE CONTINUED ...
• finish all in https://github.com/CycloneDX/cyclonedx-php-library/milestone/1
• follow https://github.com/CycloneDX/cyclonedx-php-library/blob/master/docs/dev/processes/major_version_switch.md

[jkowalleck]

I know you were waiting for this for a long time, @llaville :D
I will publish a stable RC this weekend. Then you could test it and see it if is any worth .

[llaville]

I know you were waiting for this for a long time, @llaville :D I will publish a stable RC this weekend. Then you could test it and see it if is any worth .

Yes, and of course I'll test it, but I'm not sure to have time this week-end.
I'll gave you my feedback at least on monday or later.

[jkowalleck]

released preview: v2.0.0-RC1

[llaville]

released preview: v2.0.0-RC1

👁️‍🗨️ I'll have a quick try with migration on my project tomorrow morning !

[jkowalleck]

❤️
Hope you have static code analysis in place, to helps you find positions where you need to change your code. Or you have good test coverage.
Otherwise, the API change log is pretty detailed. Let me know if I forgot to document something.

[llaville]

@jkowalleck I've just finished to migrate code from v1 to v2, and here are my first feedbacks.

Even, if my code (see my migration with commit llaville/box-manifest@e4a4058) is not so complex (I hope ;-)), it took me half an hour between change code from old format to newer, and test it to see if there are some regressions.

I think you should write a migration guide that will make the developers task more easy !

If you've time to check my commit and tell me if I'm wrong or not in my code migration.

I've tested spec 1.3 because I've a base results to compare, but spec 1.4 is pretty for me now to implement on my application (but I've no base to compare), so no feeback for this results.

[llaville]

@jkowalleck I've just tested spec 1.4 in my application (code of box-manifest) will be pushed to GitHub tomorrow (I'll be busy this afternoon and won't be online for hours), and see no regression with spec 1.3 ! Good news :)

Last but not least: results I produced (using spec 1.3 or spec 1.4) can be validate with https://github.com/CycloneDX/cyclonedx-cli#validate-command

[jkowalleck]

Thanks for testing.

I think you should write a migration guide that will make the developers task more easy !

Well, I might write a migration instruction for v2.0, then.
What kind of document could have helped you? Did you read the detailed change log that was mentioned in the release notes?
I see you have phpstan as a static code analysis. This should have found all breaking code changes. Breaking behavior is described in the mentioned change log, right?

[...] results I produced (using spec 1.3 or spec 1.4) can be validate [...]

I had no doubt on the quality of my library, as I have more than 3400 tests to assert the correctness of the models and normalization/serialization, and I have a working validator as part of the implementation as well ;-)

[llaville]

Well, I might write a migration instruction for v2.0, then. What kind of document could have helped you? Did you read the detailed change log that was mentioned in the release notes?

Mea Culpa, I didn't read the release notes, and I think it's enough. Perharps you may add a link on the project README page to learn more about how to migrate (to this release notes).

BTW, thanks for your review on my code. I appreciate a lot !!!

[llaville]

@jkowalleck By implementing support of all sbom spec version with my commit llaville/box-manifest@0ac39af on box-manifest app, I've used twice the tip provided at https://www.php.net/manual/en/language.enumerations.static-methods.php#126866

Does it make sense for you to implement such new method values in your enum Version ?

That will allow me to reduce my code :

• once when I display spec available when ask for --help application :
  -s, --sbom-spec=SBOM-SPEC SBOM specification version: 1.1, 1.2, 1.3, 1.4 [default: "1.4"]
  see at https://github.com/llaville/box-manifest/blob/0ac39af25c81b29daef99c5cfa29d4403d975ee0/src/Console/Command/Manifest.php#L85
• twice when I the DomainException : see at https://github.com/llaville/box-manifest/blob/0ac39af25c81b29daef99c5cfa29d4403d975ee0/src/Composer/ManifestFactory.php#L167
  that display such error : Unsupported spec version "1.7" for SBOM format. Expected one of these values: 1.1, 1.2, 1.3, 1.4

Goal : support as much as possible future spec version without to change the base code

[jkowalleck]

Does it make sense for you to implement such new method values in you

I do not see a reason for this.
If native PHP has no method for this, then it is probably for a good reason.
I like the way you solved it via array_column().

PS: do not want to add `values(). Who knows, this might be added natively in the next version of PHP language level support for ENUMs.
So i do not want tho shadow it.

[jkowalleck]

closed by #266
release to be triggered soon.