Skip to content

Commit e1b9999

Browse files
authored
Add brief description of (current) chisel versioning and version recommendations. (#1180) (#1250)
* Add brief description of (current) chisel versioning and version recommendations. * Respond to comments. Replace "semantic versioning" with "a form of semantic versioning". * Respond to comments - replace mmddyy with yyyymmdd. * Mention change in SNAPSHOT naming. (cherry picked from commit 041fd37)
1 parent 2333827 commit e1b9999

File tree

1 file changed

+24
-0
lines changed

1 file changed

+24
-0
lines changed

README.md

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -189,3 +189,27 @@ Also included is:
189189
- **Driver utilities**, `chisel3.Driver`, which contains compilation and test
190190
functions that are invoked in the standard Verilog generation and simulation
191191
testing infrastructure. These can also be used as part of custom flows.
192+
193+
### Which version should I use?
194+
195+
The chisel eco-system (`chisel3`, `firttl`, `dsptools`, `firrtl-interpreter`, `treadle`, `diagrammer`) use a form of semantic versioning:
196+
major versions are identified by two leading numbers, separated by a dot (i.e., `3.2`), minor versions by a single number following the major version, separated by a dot.
197+
We maintain API compatibility within a major version (i.e., `3.2.12` should be API-compatible with `3.2.0`), but do not guarantee API compatibility between major versions
198+
(i.e., APIs may change between `3.1.8` and `3.2.0`).
199+
We may introduce new definitions or add additional parameters to existing definitions in a minor release, but we do our best to maintain compatibility with previous minor releases of a major release - code that worked in `3.2.0` should continue to work un-modified in `3.2.10`.
200+
201+
We encourage chisel users (rather than chisel developers), to use release versions of chisel.
202+
The chisel web site (and GitHub repository) should indicate the current release version.
203+
If you encounter an issue with a released version of chisel, please file an issue on GitHub mentioning the chisel version and provide a simple test case (if possible).
204+
Try to reproduce the issue with the associated latest minor release (to verify that the issue hasn't been addressed).
205+
206+
If you're developing a chisel library (or `chisel` itself), you'll probably want to work closer to the tip of the development trunk.
207+
By default, the master branches of the chisel repositories are configured to build and publish their version of the code as `Z.Y-SNAPSHOT`.
208+
We try to publish an updated SNAPSHOT every two weeks.
209+
There is no guarantee of API compatibility between SNAPSHOT versions, but we publish date-stamped `Z.Y-yyyymmdd-SNAPSHOT` versions which will not change.
210+
The code in `Z.Y-SNAPSHOT` should match the code in the most recent `Z.Y-yyyymmdd-SNAPSHOT` version, the differences being the chisel library dependencies:
211+
`Z.Y-SNAPSHOT`s depend on `V.U-SNAPSHOT`s and `Z.Y-yyyymmdd-SNAPSHOT`s will depend on `V.U-yyyymmdd-SNAPSHOT`s.
212+
**NOTE**: Prior to the `v3.2-20191030-SNAPSHOT` version, we used `Z.Y-mmddyy-SNAPSHOT` to tag and name published SNAPSHOTs.
213+
214+
If you're developing a library (or another chisel tool), you should probably work with date-stamped SNAPSHOTs until your library or tool is ready to be published (to ensure a consistent API).
215+
Prior to publishing, you should verify your code against generic (no date-stamp) SNAPSHOTs, or locally published clones of the current master branches of chisel dependencies.

0 commit comments

Comments
 (0)