Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
S
sbws
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container Registry
Model registry
Operate
Environments
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
juga
sbws
Commits
2aa8266f
Commit
2aa8266f
authored
6 years ago
by
juga
Browse files
Options
Downloads
Patches
Plain Diff
Remove versioning from README
it is usually found in CONTRIBUTING
parent
0d142777
No related branches found
Branches containing commit
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
README.md
+0
-41
0 additions, 41 deletions
README.md
with
0 additions
and
41 deletions
README.md
+
0
−
41
View file @
2aa8266f
...
...
@@ -38,47 +38,6 @@ also online at https://sbws.readthedocs.io and
-
`tests/integration/`
more complex tests and/or tests that require Tor to be running
-
`tests/testnets/`
scripts and code for running mini Tor networks locally
## Boring things
### Versioning
This project follows
[
semantic versioning
][]
and thus every major version has
the potential for breaking changes. You can find information about what those
are at the following places.
-
In the CHANGELOG
[
semantic versioning
]:
https://semver.org/
In addition to the overall semantic version for sbws as a whole, there is a
simple integer version for the format in which results are stored.
Incrementing this integer requires a major version change for sbws. (Note that
the reverse is
**not**
true: a major sbws version change does not require the
integer version for the result format to change)
**Note**
: In semantic versioning, "3.4.1-dev" comes
**before**
"3.4.1". With
this in mind and assuming the current version is "3.4.1-dev": in the last few
commits leading up to a new release, the version will be updated to
-
"3.4.1" if only bug fixes
-
"3.5.0" if bug fixes and/or backwards-compatible additions/changes
-
"4.0.0" if bug fixes and/or backwards-compatible additions/changes and/or
backwards-
**in**
compatible additions/changes
Say the version is updated to "3.5.0". The commit
**immediately**
after the
tagged release should update the version to "3.5.1-dev".
**Note**
: Before version 1.0.0, we will make an effort to follow semver with a
prepended "0.". For example, "0.2.3" to "0.3.0" probably had a major breaking
change. However, we don't promise this will be followed well. Only trust the
semantic meaning of version numbers when they have reached 1.0.0. Don't worry,
we'll be 1.0.0 before we expect a full deployment on the real Tor network.
(Oh god please don't make me eat my words).
To the best of my knowledge, everything said in this section except our
conventions regarding version bump commit timing is standard semantic
versioning and spelled out in the
[
link above
][
semantic versioning
]
.
### The public API for sbws
As required by semantic versioning, the public API for sbws will not change
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment