|
11 | 11 | </header> |
12 | 12 | <nav> |
13 | 13 | <ul> |
14 | | -<li><a href="/">Home</a></li> |
15 | | -<li><a href="index.html">README</a></li> |
16 | | -<li><a href="license.html">LICENSE</a></li> |
17 | | -<li><a href="install.html">INSTALL</a></li> |
18 | | -<li><a href="docs/">Documentation</a></li> |
19 | | -<li><a href="how-to/">How To</a></li> |
20 | | -<li><a href="https://github.com/caltechlibrary/datatools">Github</a></li> |
| 14 | +<li> |
| 15 | +<a href="/">Home</a> |
| 16 | +</li> |
| 17 | +<li> |
| 18 | +<a href="index.html">README</a> |
| 19 | +</li> |
| 20 | +<li> |
| 21 | +<a href="license.html">LICENSE</a> |
| 22 | +</li> |
| 23 | +<li> |
| 24 | +<a href="install.html">INSTALL</a> |
| 25 | +</li> |
| 26 | +<li> |
| 27 | +<a href="docs/">Documentation</a> |
| 28 | +</li> |
| 29 | +<li> |
| 30 | +<a href="how-to/">How To</a> |
| 31 | +</li> |
| 32 | +<li> |
| 33 | +<a href="https://github.com/caltechlibrary/datatools">Github</a> |
| 34 | +</li> |
21 | 35 | </ul> |
22 | | - |
23 | 36 | </nav> |
24 | 37 |
|
25 | 38 | <section> |
26 | | -<h1>Release Process and tags</h1> |
27 | | - |
28 | | -<h2>Preleases and production releases</h2> |
29 | | - |
30 | | -<p>This describes a simple release process organized around semantic versioned tags.</p> |
31 | | - |
32 | | -<p>When a new release is ready it should be tag as v0.XX.XX-pre (where XX is a number) and published as a ‘pre-release’ on |
33 | | -Github. Send a note to the development group so someone other than the proposer of the release will be able to |
34 | | -indepentently evaluate the release changes. At a minimum they should run <code>bash test_cmds.bash</code> and walk through some |
35 | | -of the documentation examples. If the release is verified as ready then a new release will be cut with a tag like |
36 | | -v0.XX.XX (there the XX are the same as in v0.XX.XX-pre). E.g. v0.0.10-pre would become v0.0.10 on success.</p> |
37 | | - |
38 | | -<p>If the release fails verification, bugs need to be fixed and a new release proposed create after the fixes. |
39 | | -The “patch” number persion should be incremented in v0.XX.XX-pre (e.g. v0.0.10-pre would be followed by |
40 | | -v0.0.11-pre indicating that patches).</p> |
41 | | - |
42 | | -<p>NOTE: This means there their can be skips in the production patch numbers between release. E.g. v.0.0.9 might |
43 | | -be followed by v0.0.10-pre, v0.0.11-pre, v0.0.12-pre before a v0.0.12 appears as a production release.</p> |
44 | | - |
45 | | -<p>Production and pre-releases should include Zip files of the compiled cli to be tested by <code>bash test_cmds.bash</code>.</p> |
46 | | - |
47 | | -<h2>Dev releases</h2> |
48 | | - |
49 | | -<p>Dev release may happend from time to time as needed. They should always end in a ‘-dev’ version number (e.g. v0.0.10-dev). |
50 | | -They normally should not have any pre-compiled binaries to avoid confusion. They should be flagged as draft (pre-release) |
51 | | -on Github.</p> |
52 | | - |
53 | | -<h2>Making a release</h2> |
54 | | - |
55 | | -<ol> |
56 | | -<li>Set the version number in PACKAGE.go (where PACKAGE is the name of the package, e.g. dataset is the name of the dataset |
57 | | -package so you’d change the version number in dataset.go).</li> |
58 | | -<li>Run <code>make clean</code></li> |
59 | | -<li>Run <code>make test</code> and make sure they pass, if some fail document it if you plan to release it (e.g. GSheet integration not tested because…)</li> |
60 | | -<li>Run <code>make release</code></li> |
| 39 | +<h1 id="release-process-and-tags"> |
| 40 | +Release Process and tags |
| 41 | +</h1> |
| 42 | +<h2 id="preleases-and-production-releases"> |
| 43 | +Preleases and production releases |
| 44 | +</h2> |
| 45 | +<p> |
| 46 | +This describes a simple release process organized around semantic versioned tags. |
| 47 | +</p> |
| 48 | +<p> |
| 49 | +When a new release is ready it should be tag as v0.XX.XX-pre (where XX is a number) and published as a ‘pre-release’ on Github. Send a note to the development group so someone other than the proposer of the release will be able to indepentently evaluate the release changes. At a minimum they should run <code>bash test_cmds.bash</code> and walk through some of the documentation examples. If the release is verified as ready then a new release will be cut with a tag like v0.XX.XX (there the XX are the same as in v0.XX.XX-pre). E.g. v0.0.10-pre would become v0.0.10 on success. |
| 50 | +</p> |
| 51 | +<p> |
| 52 | +If the release fails verification, bugs need to be fixed and a new release proposed create after the fixes. The “patch” number persion should be incremented in v0.XX.XX-pre (e.g. v0.0.10-pre would be followed by v0.0.11-pre indicating that patches). |
| 53 | +</p> |
| 54 | +<p> |
| 55 | +NOTE: This means there their can be skips in the production patch numbers between release. E.g. v.0.0.9 might be followed by v0.0.10-pre, v0.0.11-pre, v0.0.12-pre before a v0.0.12 appears as a production release. |
| 56 | +</p> |
| 57 | +<p> |
| 58 | +Production and pre-releases should include Zip files of the compiled cli to be tested by <code>bash test_cmds.bash</code>. |
| 59 | +</p> |
| 60 | +<h2 id="dev-releases"> |
| 61 | +Dev releases |
| 62 | +</h2> |
| 63 | +<p> |
| 64 | +Dev release may happend from time to time as needed. They should always end in a ‘-dev’ version number (e.g. v0.0.10-dev). They normally should not have any pre-compiled binaries to avoid confusion. They should be flagged as draft (pre-release) on Github. |
| 65 | +</p> |
| 66 | +<h2 id="making-a-release"> |
| 67 | +Making a release |
| 68 | +</h2> |
| 69 | +<ol type="1"> |
| 70 | +<li> |
| 71 | +Set the version number in PACKAGE.go (where PACKAGE is the name of the package, e.g. dataset is the name of the dataset package so you’d change the version number in dataset.go). |
| 72 | +</li> |
| 73 | +<li> |
| 74 | +Run <code>make clean</code> |
| 75 | +</li> |
| 76 | +<li> |
| 77 | +Run <code>make test</code> and make sure they pass, if some fail document it if you plan to release it (e.g. GSheet integration not tested because…) |
| 78 | +</li> |
| 79 | +<li> |
| 80 | +Run <code>make release</code> |
| 81 | +</li> |
61 | 82 | </ol> |
62 | | - |
63 | | -<p>You are now ready to go to Github and create a release. If you are uploading compiled versions upload the zip files in the <em>dist</em> |
64 | | -folder.</p> |
65 | | - |
| 83 | +<p> |
| 84 | +You are now ready to go to Github and create a release. If you are uploading compiled versions upload the zip files in the <em>dist</em> folder. |
| 85 | +</p> |
66 | 86 | </section> |
67 | 87 |
|
68 | 88 | <footer> |
69 | 89 | <span><h1><A href="http://caltech.edu">Caltech</a></h1></span> |
70 | | -<span>© 2019 <a href="https://www.library.caltech.edu/copyright">Caltech library</a></span> |
| 90 | +<span>© 2021 <a href="https://www.library.caltech.edu/copyright">Caltech library</a></span> |
71 | 91 | <address>1200 E California Blvd, Mail Code 1-32, Pasadena, CA 91125-3200</address> |
72 | 92 | <span>Phone: <a href="tel:+1-626-395-3405">(626)395-3405</a></span> |
73 | 93 | <span><a href=" mailto:[email protected]" >Email Us </a></span> |
|
0 commit comments