From e61fcd30c87ad619e38df2d162cf82401e68f14c Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Tue, 5 Dec 2017 15:26:26 -0800 Subject: [PATCH 1/2] Update the versioning scheme --- CONTRIBUTING.md | 35 +++++++++++++++-------------------- 1 file changed, 15 insertions(+), 20 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 66ac74330fd7..b0f19b2c4e0b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,6 @@ -## Contribution -* Please feel free to fork and submit pull requests +# Contributing to the Python extension for Visual Studio Code + +## Contributing a pull request ### Prerequisites @@ -13,7 +14,7 @@ ### Setup -``` +```shell git clone https://github.com/microsoft/vscode-python cd vscode-python npm install @@ -40,9 +41,10 @@ Use the `Launch Extension` launch option. Run the Unit Tests via the `Launch Test` and `Launch Multiroot Tests` launch option. Currently unit tests only run on [Travis](https://travis-ci.org/Microsoft/vscode-python) -_Requirements_ +#### Requirements + 1. Ensure you have disabled breaking into 'Uncaught Exceptions' when running the Unit Tests -2. For the linters and formatters tests to pass successfully, you will need to have those corresponding Python libraries installed locally +1. For the linters and formatters tests to pass successfully, you will need to have those corresponding Python libraries installed locally ### Standard Debugging @@ -59,7 +61,6 @@ From there use the ```Extension + Debugger``` launch option. Information on our coding standards can be found [here](https://github.com/Microsoft/vscode-python/blob/master/CODING_STANDARDS.md). We have a pre-commit hook to ensure the code committed will adhere to the above coding standards. - ## Development process To effectively contribute to this extension, it helps to know how its @@ -208,17 +209,11 @@ it should have an appropriate `closed-` label. ### Versioning Starting in 2018, the extension switched to -[calendar versioning](http://calver.org/) from -[semantic versioning](https://semver.org/) since the extension -auto-updates and thus there is no need to care about its version -number in terms of backwards-compatibility. As such, the major version -is the current year, the minor version is the week of the year, and -the micro version is how many releases there have been that week -(starting at 0). For example, a release made on July 2, 2018 would -have a version number of `2018.27.0`. To easily calculate the first -release of a week, you can run the following Python code: -```python -import datetime -year, week, _ = datetime.date.today().isocalendar() -print(f"{year}.{week}.0") -``` +[calendar versioning](http://calver.org/) since the extension +auto-updates and thus there is no need to track its version +number for backwards-compatibility. As such, the major version +is the current year, the minor version is the current month, and +the micro version is how many releases there have been that month in +the year (starting at 0). For example, the first release in July 2018 +would be `2017.7.0`, the second release that month would be +`2017.7.1`, etc. From 7a10b2e3847581a998ae3cfbbc4eb7847551d312 Mon Sep 17 00:00:00 2001 From: Brett Cannon Date: Wed, 6 Dec 2017 10:50:43 -0800 Subject: [PATCH 2/2] Actually use the proper year for the example --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b0f19b2c4e0b..b459867ba502 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -215,5 +215,5 @@ number for backwards-compatibility. As such, the major version is the current year, the minor version is the current month, and the micro version is how many releases there have been that month in the year (starting at 0). For example, the first release in July 2018 -would be `2017.7.0`, the second release that month would be -`2017.7.1`, etc. +would be `2018.7.0`, the second release that month would be +`2018.7.1`, etc.