Comments (6)
That makes sense to me. Yes, I'd think that #21 and #22 are major enough
to warrant being in 5.0.
On Tue, Aug 20, 2013 at 6:00 PM, Joe Hamman [email protected]:
I’d like to propose a standard for determining release names for VIC based
on the Semantic Versioning 2.0.0 http://semver.org/spec/v2.0.0.htmlstandard. The standard proposes a version format of X.Y.Z
(Major.Minor.Patch). According to the standard:Bug fixes not affecting the API increment the patch version, backwards
compatible API additions/changes increment the minor version, and backwards
incompatible API changes increment the major versionI’ll suggest that the VIC API can be sufficiently defined by the existing
user interface. For this reason, major releases would be invoked when there
is a change in the required inputs. As the VIC code becomes more modular in
VIC 5.0, the defined API should be more specifically defined.Lastly, I should acknowledge that this is essentially what has been done
in the past; now with a clear explanation. The major changes are to loose
the 4th digit (i.e. VIC.4.1.2.i) and to select the release name based on
the contents of it's changes. This would have some impact on what we
include in VIC.4.2.0. Changes such as #21https://github.com/UW-Hydro/VIC/issues/21and
#22 #22 would need to wait until
VIC.5.0.0.Thoughts?
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49
.
from vic.
I agree mostly. However, removing options that no one uses shouldn't require a major (4-5) upgrade, so I suggest we keep it in. But I do not feel particularly strongly about that.
Bart
On Aug 20, 2013, at 7:00 PM, Joe Hamman [email protected] wrote:
I’d like to propose a standard for determining release names for VIC based on the Semantic Versioning 2.0.0 standard. The standard proposes a version format of X.Y.Z (Major.Minor.Patch). According to the standard:
Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version
I’ll suggest that the VIC API can be sufficiently defined by the existing user interface. For this reason, major releases would be invoked when there is a change in the required inputs. As the VIC code becomes more modular in VIC 5.0, the defined API should be more specifically defined.
Lastly, I should acknowledge that this is essentially what has been done in the past; now with a clear explanation. The major changes are to loose the 4th digit (i.e. VIC.4.1.2.i) and to select the release name based on the contents of it's changes. This would have some impact on what we include in VIC.4.2.0. Changes such as #21 and #22 would need to wait until VIC.5.0.0.
Thoughts?
—
Reply to this email directly or view it on GitHub.
from vic.
I'm closing this since we have settled on a path forward.
4.2.0
will be the release of the current develop branch.5.0.0
will be the next major release, including the same physics as4.2.0
, restructured to accommodate multiple drivers.5.1.0
will be the first minor release in VIC.5 with new physics.
Patches may be applied to any of these releases as necessary using the third digit (e.g. 4.2.1
).
from vic.
For 4.X releases we will stick with the convention that bug fixes are identified with lowercase, which means that tag 4.2.1
will be renamed 4.2.a
and the next bug release will be 4.2.b
.
From 5.X on we will use the convention specified above:
<major release>.<minor release>.<bug fix release>
all in numbers from [0, inf>.
from vic.
The only tag in the 4.X track to use the alphabetic bug fix was 4.1.2
. Looking at the list of past VIC tags, the third digit has never been alphabetic. If you want to be consistent with 4.1.2.<>
, we would need to continue with the 4 digit tag name that was used for that track only, e.g 4.2.0.a
. To me, that does not seem necessary, and I would prefer to stick with a 3 digit all numeric tag name.
from vic.
4.1.2 was the release immediately predating 4.2 and uses a letter to designate a bug release. We will stick with that for 4.2
Bug release 1: 4.2.a
Bug release 2: 4.2.b
Since there will be no further releases there is no need at all for a .0. in between (there will never be a 4.2.1, which is the whole point here). It is again misleading to put one there.
It has been a bit of a hodgepodge up to this point. I want to be consistent from 5.X on, but I want to avoid confusion for 4.X.
I'll open an issue to retag the hotfix
On Jan 22, 2015, at 10:12 AM, Joe Hamman [email protected] wrote:
The only tag in the 4.X track to use the alphabetic bug fix was 4.1.2. Looking at the list of past VIC tags, the third digit has never been alphabetic. If you want to be consistent with 4.1.2.<>, we would need to continue with the 4 digit tag name that was used for that track only, e.g 4.2.0.a. To me, that does not seem necessary, and I would prefer to stick with a 3 digit all numeric tag name.
—
Reply to this email directly or view it on GitHub.
from vic.
Related Issues (20)
- Run RVIC prompt permissions are not enough, ask how to resolve
- VIC_Routing cannot operate
- classic and image drivers fail to build - Ubuntu 22.04 HOT 5
- NetCDF: Invalid dimension ID or name: Error getting dimension id MISSING HOT 1
- Segmentation fault when running image driver with LAKES = TRUE (cells with and without lakes) HOT 1
- layer 0 mineral bulk density (0.77000) must be less than mineral soil density(0.57000)
- New - Compile failure -- Resolved HOT 1
- ERROR: set_force_type.c:138: errno: None: Must supply netCDF variable name for WIND forcing file number 1
- [ERROR] ../../vic_run/src/CalcAerodynamic.c:119: errno: Numerical result out of range: Trunk space height below "center" of lower boundary
- Resloved--Can't Run vic_image.exe -g global,txt, and the error occured in the file of set_forcing_type.c HOT 1
- [QUESTION] Soil moisture fraction output with VIC v5
- Wpwp_FRACT MUST be <= Wcr_FRACT.
- multiple definition of 'xxx'; ... first defined here HOT 1
- Maximum Energy Error
- Clarification of forcing units HOT 1
- Why are there negative values in the sublimation of the snow in the canopy intercept in VIC 4.2.d?
- Compilation error with VIC5.1.0: "collect2: error: ld returned 1 exit status" HOT 3
- Erroneous VIC version reporting in image driver?
- VIC Image Driver CPU Limited? Ways to increase memory use? HOT 1
- an error in docker_vic HOT 2
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 vic.