Merge cmake updates from PR #140 into release/public-v1

[noaa-emc]

Merge cmake updates from PR #140 into release/public-v1

[fossell]

@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!

[aerorahul]

@fossell
I would suggest not bringing develop into release/public-v1. I don't think we want to mess with release/public-v1 branch. It is a released branch, and should be fixed hereafter. I would rather suggest creating a new branch from release/public-v1 (say feature/public-v1.1.0-rc). Ideally, one would do that from develop, even if it is an incremental change from release/public-v1. Otherwise, when release/public-v1.1 is released and we wish to merge any changes back in develop, one would have to cherry pick again.

The changes we want to checkout from develop and cherry pick into feature/public-v1.1.0-rc are from:

CMakeLists.txt
VERSION
.gitmodules
.gitignore
cmake/PackageConfig.cmake.in
sorc/ncep_post.fd/CMakeLists.txt

develop::sorc/ncep_post.fd/CMakeLists.txt added new files in the sources list, so we may want to cross-reference, and make sure the filelist is correct.

We can bump the VERSION to 1.1.0 now or wait till the changes settle and the release candidate branch is ready for final tagging and release. I would suggest the latter.

[climbfuji]

@fossell
I would suggest not bringing develop into release/public-v1. I don't think we want to mess with release/public-v1 branch. It is a released branch, and should be fixed hereafter. I would rather suggest creating a new branch from release/public-v1 (say feature/public-v1.1.0-rc). Ideally, one would do that from develop, even if it is an incremental change from release/public-v1. Otherwise, when release/public-v1.1 is released and we wish to merge any changes back in develop, one would have to cherry pick again.

The changes we want to checkout from develop and cherry pick into feature/public-v1.1.0-rc are from:

CMakeLists.txt
VERSION
.gitmodules
.gitignore
cmake/PackageConfig.cmake.in
sorc/ncep_post.fd/CMakeLists.txt

develop::sorc/ncep_post.fd/CMakeLists.txt added new files in the sources list, so we may want to cross-reference, and make sure the filelist is correct.

We can bump the VERSION to 1.1.0 now or wait till the changes settle and the release candidate branch is ready for final tagging and release. I would suggest the latter.

@aerorahul please note that the branching strategy for the UFS releases has been discussed and decided upon in length. The rules are:

• major releases (v1.0, v2.0) are created from develop (in the absence of master) by creating a major release branch, e.g. release/public-v1
• all minor releases and bugfix releases are created from that major release branch, e.g. v1.1.0 is created frorm release/public-v1, as well as v1.1.1 etc.
• there is no separate release branch v1.1.0 or the like
• this is, however, for the model components and not strictly for external components, such as the NCEP libraries

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).

[aerorahul]

@climbfuji
I am not arguing what the UFS wants to call their releases.
Also, I said ideally.
Is v1.1.0 just a bugfix release?
How will the public/user distinguish between release/public-v1 and this new bugfix release? Will there be a branch or a tag or just a SHA to go by?

May be there is a document that describes all this. If so, please point me to that document.

[climbfuji]

@climbfuji
I am not arguing what the UFS wants to call their releases.
Also, I said ideally.
Is v1.1.0 just a bugfix release?
How will the public/user distinguish between release/public-v1 and this new bugfix release? Will there be a branch or a tag or just a SHA to go by?

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.

[climbfuji]

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

[aerorahul]

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 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.

[climbfuji]

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 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.

[junwang-noaa]

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> .

[fossell]

@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.

[climbfuji]

@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.

[aerorahul]

closing unresolved issue.