Release Naming Conventions

[jhamman]

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 lose 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?

[tbohn]

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 notifications@git.luolix.topwrote:

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

[bartnijssen]

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 notifications@github.com 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.

[jhamman]

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

[bartnijssen]

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

[jhamman]

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.

[bartnijssen]

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 notifications@github.com 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.