12/30/2023 0 Comments Formz xyz absolute![]() ![]() ![]() ![]() Those that don't want or need a build number could simply leave it off and it would default to zero and perhaps even be hidden. However, if you defined it such that missing fields are zero, then the old revisions still work rather than break.Īlso, by having a less rigid system you could instantly move to X.Y.Z.A to be compatible with those that want to use a build number along with the version information. Likewise if in the future you decide that X.Y.Z is not good enough and need to add another field, then currently the entire world breaks since if you go to X.Y.Z.A then it would mandate that X.Y.Z is invalid. users should be allowed to use what I described aboveĪnd if the semver system expects X.Y.Z and only X is specified then X.0.0 would be used (Y and Z were not specified and so default to zero) and it all works. What is more important than a rigid format is to define how parsing should work.Īnd if defined properly, an arbitrary system can be used and yet still be compatible the current recommend numbering system. There is no need to be so strict with the numbering system and it locks you into this without any ability to extend in the future. So for example, you are currently mandating a very rigid system. And that is what people will need to handle in their parsers. The reason it future proofs things is that it allows an arbitrary number of versioning digits. ![]() The reason why I brought up this discussion is because I'm in the process of refactoring my version and expression parsers where I want to avoid code duplication in the following scenarios So again, I changed the title of the issue so that it's clear I'm not proposing to change the spec but rather to discuss the matter in order to see what community thinks of it. Having said that, I believe you've got a the use cases you pointed out are widely used in package managers for the SemVer ranges/expressions, although in a slightly different way: when the actual minor or patch version isn't important you would put * instead of it ( 1.2.*), whereas 1.2 would be identical to 1.2.0. I guess this one can be easily worked out through conventions, this is what the spec is all about.People who use the short form are pretty much aware of SemVer. Consistency is great but does omitting 0 versions really makes it confusing?.I do favor explicit over implicit as well but doubt I would forget about the patch version.use versions ( 1.2.0) if you want to reference a specific (semver valid) while I tend to mostly agree with you I wouldn't be that adamant about some of your points.use MAJOR.MINOR version numbers ( 1.2) if you want to say something that is true for all associated patch versions.use MAJOR version numbers ( 1) if you want to say something that is true for all associated minor and patch versions.a certain edge case now returns an error code instead of throwing an exception) but the general statements are valid for all patch versions of this minor version. If patch versions have an influence on the output of a specific function this could additionally be noted in the API documentation (e.g. However something more specific, like your API documentation would only be valid for a specific minor version, like 1.2. Any substantial changes to the data model (or processing pipeline) would require a new major version. Besides the already mentioned reasons, I also think that versions numbers in the form of 1 and 1.2 also have their place within the semantic versions context, but they do have a different meaning than 1.0.0 or 1.2.0.įor instance if you describe something general/conceptional like the general data model or a processing pipeline of your application, you could say that this is for version 1 (regardless of the minor and patch versions). I am also against the optional minor and patch versions. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |