-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge cmake updates from PR #140 into release/public-v1 #146
Comments
@fossell The changes we want to checkout from
We can bump the |
@aerorahul please note that the branching strategy for the UFS releases has been discussed and decided upon in length. The rules are:
What we really have to decide is whether we want to pass those changes that are currently in develop into release v1.1.0 or not. I would say we hold back until we have the updated NCEPLIBS-external working and then reassess. There is no new functionality except the UFS_UTILS and EMC_post bug fixes that we need for MRW App release 1.1.0. Maybe it is enough to just cherry-pick those into the existing public/release-v1 branches of the two repositories and leave the other NCEPLIBS-* and (most of) the NCEPLIBS umbrella build as-is. For SRW App release v1.0, we would then create an entirely new release/public-v2 for the NCEPLIBS and prerequisites, and release SRW App v1.0 with v2.0 of the NCEPLIBS (and hopefully a MRW App v2.0 in early 2021 with v2.0 or 2.x of NCEPLIBS). |
@climbfuji - Thanks Dom, I was just responding with the branching strategy discussed last week. No rush on my end, it's up to your development team to decide what cmake mods need to go into release/public-v1 in preparation for v1.1.0 release. Just keep me posted! |
@climbfuji May be there is a document that describes all this. If so, please point me to that document. |
No offense, so many moving parts. To answer your question: tags - everything was tagged as v1.0.0 when the release came out in March. Whatever we want to bring into release v1.1.0 (which is a minor release / feature upgrade; for NCEPLIBS, there are bug fixes in UFS_UTILS and EMC_post, and the capability to process netCDF files - i.e. a feature upgrade and not a bugfix) will go into the release/public-v1 branches and those then get tagged as v1.1.0. It is probably the only time in history that a release number of NCEPLIBS matches 1:1 the release number of a UFS app, so this adds to the confusion. |
Here is a link to the visualization/discussion. The solution we agreed on last Friday is on slides 5 and 6. https://docs.google.com/presentation/d/1qCk0hwDMxeSlnGHES6gyDSwcrh43jhxgnQYWLTOpZWU/edit?usp=sharing |
slide 2 is Either way, thanks for the clarification. |
I know. There is no ideal solution here. The git-flow approach in slide 2 as used for WRF is something EMC did not want to adopt. We'll work around all this, and as I said this is strictly speaking for the ufs model and its components, not necessarily for external libraries. |
I think we may need to discuss what features that will be added to release
branch. My understanding is that only bug fixes or fixes for broken
features in release branch need to go to release branch, basically the
release branch should be in maintenance mode without new development. If
new feature developed from develop branch is required, maybe it is time to
create the new release branch from develop branch. I am confused about
slide 5 that brings develop branch changes to the release branch.
…On Mon, Jun 29, 2020 at 5:34 PM Dom Heinzeller ***@***.***> wrote:
slide 2 is git-flow. This is the gold standard, so to speak.
slide 5 is UFS suggested flow and *NOT* entirely git-flow.
The offending arrows are the ones originating from develop and being
merged in the bugfix orminor releases.
I understand bugfixes can go both in bugfix release and develop, but that
is typically done with 2 branches, one off-of develop and other off-of
release branch. To have a wholesale arrow from develop to release branch
is a bit misguided to call it git-flow.
Also, lumping build system andetc. is a bit vague. E.g., if someone
proposes using scons <https://scons.org/> instead of cmake, it
technically satisfies a minor/bugfix release criteria. I suppose, it
depends on who you ask.
Either way, thanks for the clarification.
I know. There is no ideal solution here. The git-flow approach in slide 2
as used for WRF is something EMC did not want to adopt. We'll work around
all this, and as I said this is strictly speaking for the ufs model and its
components, not necessarily for external libraries.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AI7D6TOTNQB45E7I6SMIQZTRZECHHANCNFSM4OLMQLEA>
.
|
@junwang-noaa - Yes, I think that's the idea and why I started this Issue to find out from @aerorahul and UFS developers if any of those cmake mods that went into develop branch need to be brought into the release/public-v1 branch for the v1.1 release. I think bringing in develop branch changes into the release branch is done on a case by case basis to be determined by code managers, hence this Issue. It sounds like these changes may not be necessary for v1.1, but I leave that up to the UFS MRW folks to decide. |
@fossell thanks for explaining this so well. |
closing unresolved issue. |
…NERS Change CODEOWNERS to correct my GitHub account name and add Jamie
@aerorahul - Do the updates that went into develop on #140 need to be brought into the release/public-v1 branch in preparation for v1.1 release?
There are major differences between develop and release/public-v1 right now, so I'd like to cherry-pick the commit to bring it into release/public-v1, as opposed to merging the full develop (UFS v2.0 will branch from develop). I started this on my fork, however I'm unsure about a conflict with gitmodules settings for cmake. Should branch be modified to "develop" in release/public-v1? Can you please confirm and/or submit a PR with this cherry-pick and conflicts resolved to release/public-v1.
The text was updated successfully, but these errors were encountered: