-
Notifications
You must be signed in to change notification settings - Fork 392
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
Release Naming Conventions #49
Comments
That makes sense to me. Yes, I'd think that #21 and #22 are major enough On Tue, Aug 20, 2013 at 6:00 PM, Joe Hamman notifications@git.luolix.topwrote:
|
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'm closing this since we have settled on a path forward.
Patches may be applied to any of these releases as necessary using the third digit (e.g. |
For 4.X releases we will stick with the convention that bug fixes are identified with lowercase, which means that tag From 5.X on we will use the convention specified above:
all in numbers from [0, inf>. |
The only tag in the 4.X track to use the alphabetic bug fix was |
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 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
|
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:
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?
The text was updated successfully, but these errors were encountered: