Comments (12)
@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!
from upp.
@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.
from upp.
@fossell
I would suggest not bringingdevelop
intorelease/public-v1
. I don't think we want to mess withrelease/public-v1
branch. It is a released branch, and should be fixed hereafter. I would rather suggest creating a new branch fromrelease/public-v1
(sayfeature/public-v1.1.0-rc
). Ideally, one would do that fromdevelop
, even if it is an incremental change fromrelease/public-v1
. Otherwise, whenrelease/public-v1.1
is released and we wish to merge any changes back indevelop
, one would have tocherry pick
again.The changes we want to checkout from
develop
and cherry pick intofeature/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
to1.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).
from upp.
@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.
from upp.
@climbfuji
I am not arguing what the UFS wants to call their releases.
Also, I saidideally
.
Is v1.1.0 just a bugfix release?
How will the public/user distinguish betweenrelease/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.
from upp.
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
from upp.
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.
from upp.
slide 2 is
git-flow
. This is the gold standard, so to speak.
slide 5 is UFS suggested flow and NOT entirelygit-flow
.
The offending arrows are the ones originating fromdevelop
and being merged in thebugfix
orminor
releases.
I understand bugfixes can go both inbugfix release
anddevelop
, but that is typically done with 2 branches, one off-ofdevelop
and other off-ofrelease
branch. To have a wholesale arrow fromdevelop
torelease
branch is a bit misguided to call itgit-flow
.
Also, lumping build system andetc.
is a bit vague. E.g., if someone proposes using scons instead ofcmake
, 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.
from upp.
from upp.
@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.
from upp.
@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.
from upp.
closing unresolved issue.
from upp.
Related Issues (20)
- Write out HGT for hydrostatic run and omega from the model output HOT 11
- The Read the Docs documentation of namelist entries is bare. HOT 1
- Ensemble member information missing in aerosol fields HOT 3
- Solve the RRFS GTG difference between NCAR and EMC run
- Add instantaneous clear sky downward solar irradiance to RRFS
- Correction to rt.sh spack-stack paths
- Update UPP wcoss2 model to use recently implemented operational G2tmpl lib v1.12.0 HOT 1
- Bug in prob values denoted in QPFARI and QPFFFG fields in RRFS HOT 1
- Clean up compile warnings within the UPP code HOT 3
- UPP on C6 HOT 2
- Bug in calculation of vertically summed smoke emissions HOT 1
- Bug in labeling of run total accumulated fields in sub-hourly output. HOT 1
- 1-h avg MASSDEN fields in RRFS need to be PM2.5 and PM10 HOT 1
- extraneous GSD_ in number concentration variable names HOT 7
- number concentration on pressure levels HOT 2
- Some variables are missing from DEALLOCATE.f
- switch to using X.Y.Z as a version number, instead of named tags HOT 2
- UPP sends invalid empty keys to g2tmpl, and g2tmpl lacks proper error handling HOT 1
- Numerous "255 not found in table 4.5" errors from UPP
- Sync the RRFS hotfix #967 and #968 in develop
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from upp.