Adjust versioning to new format #9695
Conversation
|
It actually appears that a trailing newline in |
|
Where is the patch version going to be stored and incremented? |
|
Right, it defaults to 0 ... so how will we change it to 1 when we start working on the first patch release? (Is the idea that the Jenkinsfile will be different on each branch?) |
|
Yeah, exactly, just like we would have updated the old default from major version 1, minor version 5 to major version 1, minor version 6 for the next release |
MariaSemple
changed the title
CMakeGlobals.txt
Outdated
| else() | ||
| set(CPACK_PACKAGE_VERSION_PATCH $ENV{RSTUDIO_VERSION_PATCH}) | ||
| endif() | ||
| set(CPACK_PACKAGE_VERSION "${CPACK_PACKAGE_VERSION_MAJOR}.${CPACK_PACKAGE_VERSION_MINOR}.${CPACK_PACKAGE_VERSION_PATCH}") | ||
| set(CPACK_PACKAGE_VERSION_SUFFIX $ENV{RSTUDIO_VERSION_SUFFIX}) |
There was a problem hiding this comment.
Should we have a default suffix if one isn't defined in the environment? (Bonus points if it helps distinguish development builds, which typically don't have env vars set, from lab builds, which do; a job formerly done by the 9/99 parts of the version)
There was a problem hiding this comment.
What do you think about -developer+999 or something like that?
There was a problem hiding this comment.
I'm a fan. Maybe just -dev+999 for brevity?
| @@ -348,6 +348,17 @@ SEXP rs_rstudioEdition() | |||
|
|
|||
| // get version | |||
| SEXP rs_rstudioVersion() | |||
| { | |||
| std::string processedVersion = RSTUDIO_VERSION; | |||
There was a problem hiding this comment.
Would it be easier and/or less fragile to compose this from the component variables (RSTUDIO_VERSION_MAJOR, etc.)?
There was a problem hiding this comment.
We can do that - we'll still have to apply regex on the RSTUDIO_VERSION_SUFFIX portion to strip the release channel and/or pro from the string
CALENDAR_VERSION
Outdated
| @@ -0,0 +1 @@ | |||
| 2021.09 | |||
There was a problem hiding this comment.
Not something we have to change in this PR, but we're starting to accumulate a large number of these files at the repo root. I wonder if we should just have one that contains calendar version, flower, build type, etc.
There was a problem hiding this comment.
I think that would add complexity to the parsing system. What about moving them to their own folder, like version or release or something?
| @@ -348,6 +348,17 @@ SEXP rs_rstudioEdition() | |||
|
|
|||
| // get version | |||
| SEXP rs_rstudioVersion() | |||
| { | |||
| std::string processedVersion = RSTUDIO_VERSION; | |||
| processedVersion = boost::regex_replace(processedVersion, boost::regex("(?:-[a-zA-Z]*)?\\+"), "."); | |||
There was a problem hiding this comment.
As a habit, I think it's usually better to hoist the boost::regex() object into its own variable, since (at least for other regex functions) the regular expression usually needs to live at least as long as other objects derived from using it (e.g. when finding and generating regex matches).
It's probably fine here, but pointing this out just in case.
There was a problem hiding this comment.
I didn't know that! Is that primarily for when you'll iterate through multiple matches in a single input?
At any rate, I agree that it's necessary here since we keep no objects except the resulting string, which can't have a dependence on anything in boost.
|
@jmcphers Updated the about page (see screenshots). I think If the server homepage needs updates, I'll need to open a Pro PR for that after this one is merged. |
Co-authored-by: Kevin Ushey <kevin@rstudio.com>
…rstudio into feature/allow-fixed-release-ver
Intent
Addresses Pro #2788.
Approach
The
CALENDAR_VERSIONfile must be present in the root of the repo.Here is the output for RStudio.Version() from an R terminal in a locally built copy:
Updated about page:
Pro would show
Build 16.pro1.Automated Tests
N/A - build system change.
QA Notes
When we release a branch, the version should not continue to increment with the date on that branch for future builds. You can test locally by creating a release version file and giving it a value other than the current year and month.
Upgrades and downgrades should work as expected. I did some preliminary testing on this using dpkg and rpm version comparators and we are not expecting issues here.
Checklist
NEWS.md