Skip to content

Commit f2f5668

Browse files
rsdoielrsdoiel
committed
fixed templates
1 parent 4e88bfd commit f2f5668

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

84 files changed

+5317
-3901
lines changed

‎RELEASES.html

+68-48
Original file line numberDiff line numberDiff line change
@@ -11,63 +11,83 @@
1111
</header>
1212
<nav>
1313
<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>
2135
</ul>
22-
2336
</nav>
2437

2538
<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 &lsquo;pre-release&rsquo; 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 &ldquo;patch&rdquo; 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 &lsquo;-dev&rsquo; 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&rsquo;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&hellip;)</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>
6182
</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>
6686
</section>
6787

6888
<footer>
6989
<span><h1><A href="http://caltech.edu">Caltech</a></h1></span>
70-
<span>&copy; 2019 <a href="https://www.library.caltech.edu/copyright">Caltech library</a></span>
90+
<span>&copy; 2021 <a href="https://www.library.caltech.edu/copyright">Caltech library</a></span>
7191
<address>1200 E California Blvd, Mail Code 1-32, Pasadena, CA 91125-3200</address>
7292
<span>Phone: <a href="tel:+1-626-395-3405">(626)395-3405</a></span>
7393
<span><a href="mailto:[email protected]">Email Us</a></span>

0 commit comments

Comments
 (0)