Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Kerby Geffrard <[email protected]>
- Loading branch information
Signed-off-by: Kerby Geffrard <[email protected]>
ca1fddfThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@geffrak Are there plans to update minor and patch versions more regularly?
We've been building various commits between major releases and so far been having to make up our own versioning. It'd be more preferable to rely on official versioning as it would simplify matching up our builds to particular commits. We could even potentially hook up our CI to (attempt to) automatically build when new commits are pushed.
Also, is there a particular reason that you've chosen to run with 1.0.0 -> 2.0.0 versioning rather than 2023.0.0 -> 2024.0.0 versioning used on the commercial product?
ca1fddfThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi RyZeePy,
We are still thinking on how often we will release major, minor or patch. We did release 2.0.0 because we have made significant amount of testing on this branch because of all the testing hours that we have put on the commercial released which is based on this commit. We didn't want to use the same version numbering as the commercial release because it not clear if all commercial release will align with Open RV release, therefore didn't want to create expectations. Moreover, we assume Autodesk won't be the one having a dependent projects in the future. When you say, "it would be more preferable to rely on official versioning...", what do you mean?
ca1fddfThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I say "official versioning" I just mean versioning defined by yourselves in the project. For other projects which we build, we generally adhere to their version numbers when releasing internally unless we need to make edits to the source, in which case we add our own additional patch version. So far, when building OpenRV, we've had to just add arbitrary patch numbers to our internal versioning and relied on storing the commit hash to refer back to which commit the build came from.
Ideally, it'd be nice to have an identifiable version number for each commit even if they're not actually a tagged as a release. At least then we would have a unique version number to use for our internal releases regardless of whether they use a tagged release or an intermediate commit.
ca1fddfThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, for a 2.0 release I feel the information provided with the release: https://github.com/AcademySoftwareFoundation/OpenRV/releases/tag/v2.0.0 is really limited a to WHY this is a 2.0.0 release and what it brings compared to older versions.
A changelog would be nice, and if there's no major changes to show - then at least add the explanation as what the idea is with releasing 2.0.0 with that release.