hoe-halostatue 3.0.0 → 3.0.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (11) hide show
  1. checksums.yaml +4 -4
  2. data/CHANGELOG.md +19 -10
  3. data/CODE_OF_CONDUCT.md +47 -46
  4. data/CONTRIBUTING.md +24 -23
  5. data/LICENCE.md +19 -15
  6. data/README.md +71 -66
  7. data/SECURITY.md +2 -2
  8. data/lib/hoe/halostatue/gemspec.rb +4 -2
  9. data/lib/hoe/halostatue/git.rb +1 -1
  10. data/lib/hoe/halostatue/version.rb +1 -1
  11. metadata +10 -9
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: 91f8c281c6cce65f4b2eaa54857bd77773b24862c6bba773cce078c6a7019d99
4
- data.tar.gz: f417d9e2f28ccd274bcb8a37869fba45b87003d7a5ab9b3804f716dda6f85d01
3
+ metadata.gz: 8342ac9829ef87b580c84205ccc14404745ab1946363d542dae9c0a883b99fb2
4
+ data.tar.gz: 844e54583dba4e977fcffd925eaec4473e3b4bb1074c2f966513b78f7119d7f6
5
5
  SHA512:
6
- metadata.gz: 8e972a821fc43ac4a087f58f11e8f54a5c7fd2a2aaaac6353c1c1548f24598c33ea2c34ec90a6720fa73e13c49c6772d07921c5ee28491d251bfc3009027717d
7
- data.tar.gz: 3801533925fad4cdcf691f0ab762e0e5218574adfd069bac142915569c44ca11fd5698010e605ce493a3010ba22dbeb7c64b98da55291a2f52e0f62b47e25118
6
+ metadata.gz: e859c5b7c61dd42f66c6304aacad81ec94c24fa0095a89220aa475ea299827e25c9b5ab86f668cc6418274ee58126dd3ed05752e717fb5b6366e5780c6f1a95c
7
+ data.tar.gz: 80e42229c06e78f39aedeb182e46a4455747841f095d2a2c9b4adf2970d2e24449a09b95b4b0f23d815e135a9388c1200a40462c7e37b25913e1e1d49b2e68de
data/CHANGELOG.md CHANGED
@@ -1,19 +1,28 @@
1
1
  # hoe-halostatue Changelog
2
2
 
3
+ ## 3.0.2 / 2026-09-20
4
+
5
+ - Fix an error in YAML safe loading with `Date`, which needs `require 'date'`.
6
+ - Various local and CI development tooling updates.
7
+
8
+ ## 3.0.1 / 2026-01-22
9
+
10
+ - Fix an error in pre-release value checking.
11
+
3
12
  ## 3.0.0 / 2026-01-19
4
13
 
5
- - Replaced `hoe-gemspec2` with an internal implementation that improves support
6
- for [reproducible builds][rb]. The included plugin `hoe-rubygems` was also
7
- removed as it's duplicative of this work.
14
+ - Replaced `hoe-gemspec2` with an internal implementation that improves
15
+ support for [reproducible builds][rb]. The included plugin `hoe-rubygems`
16
+ was also removed as it's duplicative of this work.
8
17
 
9
18
  - Replaced `hoe-markdown` with an internal implementation that uses
10
19
  [`kramdown`][kd] for AST-aware Markdown processing when converting GitHub
11
- references to links. The new implementation correctly handles edge cases like
12
- email addresses, Mastodon handles, code blocks/spans, existing links, and
13
- malformed patterns. This was written with the assistance of Kiro.
20
+ references to links. The new implementation correctly handles edge cases
21
+ like email addresses, Mastodon handles, code blocks/spans, existing links,
22
+ and malformed patterns. This was written with the assistance of Kiro.
14
23
 
15
- - Internal restructuring was performed to improve readability and optimize some
16
- flows.
24
+ - Internal restructuring was performed to improve readability and optimize
25
+ some flows.
17
26
 
18
27
  ## 2.1.2 / 2026-01-17
19
28
 
@@ -46,8 +55,8 @@
46
55
  URLs work.
47
56
 
48
57
  - Added a `trusted_release` mode that skips the need for a `VERSION` specifier
49
- on the release task and ensures that features which impede automated releases
50
- are disabled.
58
+ on the release task and ensures that features which impede automated
59
+ releases are disabled.
51
60
 
52
61
  - Enabled trusted publishing for this repo.
53
62
 
data/CODE_OF_CONDUCT.md CHANGED
@@ -9,9 +9,9 @@ dignity, rights, and contributions of all individuals, regardless of
9
9
  characteristics including race, ethnicity, caste, color, age, physical
10
10
  characteristics, neurodiversity, disability, sex or gender, gender identity or
11
11
  expression, sexual orientation, language, philosophy or religion, national or
12
- social origin, socio-economic position, level of education, or other status. The
13
- same privileges of participation are extended to everyone who participates in
14
- good faith and in accordance with this Covenant.
12
+ social origin, socio-economic position, level of education, or other status.
13
+ The same privileges of participation are extended to everyone who participates
14
+ in good faith and in accordance with this Covenant.
15
15
 
16
16
  ## Encouraged Behaviors
17
17
 
@@ -23,8 +23,8 @@ culture, background, or native language.
23
23
  With these considerations in mind, we agree to behave mindfully toward each
24
24
  other and act in ways that center our shared values, including:
25
25
 
26
- 1. Respecting the **purpose of our community**, our activities, and our ways of
27
- gathering.
26
+ 1. Respecting the **purpose of our community**, our activities, and our ways
27
+ of gathering.
28
28
  2. Engaging **kindly and honestly** with others.
29
29
  3. Respecting **different viewpoints** and experiences.
30
30
  4. **Taking responsibility** for our actions and contributions.
@@ -49,48 +49,49 @@ Conduct.
49
49
  inappropriately intimate in the context or purpose of the community.
50
50
  5. **Violating confidentiality**. Sharing or acting on someone's personal or
51
51
  private information without their permission.
52
- 6. **Endangerment.** Causing, encouraging, or threatening violence or other harm
53
- toward any person or group.
52
+ 6. **Endangerment.** Causing, encouraging, or threatening violence or other
53
+ harm toward any person or group.
54
54
  7. Behaving in other ways that **threaten the well-being** of our community.
55
55
 
56
56
  ### Other Restrictions
57
57
 
58
58
  1. **Misleading identity.** Impersonating someone else for any reason, or
59
59
  pretending to be someone else to evade enforcement actions.
60
- 2. **Failing to credit sources.** Not properly crediting the sources of content
61
- you contribute.
62
- 3. **Promotional materials**. Sharing marketing or other commercial content in a
63
- way that is outside the norms of the community.
64
- 4. **Irresponsible communication.** Failing to responsibly present content which
65
- includes, links or describes any other restricted behaviors.
60
+ 2. **Failing to credit sources.** Not properly crediting the sources of
61
+ content you contribute.
62
+ 3. **Promotional materials**. Sharing marketing or other commercial content in
63
+ a way that is outside the norms of the community.
64
+ 4. **Irresponsible communication.** Failing to responsibly present content
65
+ which includes, links or describes any other restricted behaviors.
66
66
 
67
67
  ## Reporting an Issue
68
68
 
69
69
  Tensions can occur between community members even when they are trying their
70
- best to collaborate. Not every conflict represents a code of conduct violation,
71
- and this Code of Conduct reinforces encouraged behaviors and norms that can help
72
- avoid conflicts and minimize harm.
70
+ best to collaborate. Not every conflict represents a code of conduct
71
+ violation, and this Code of Conduct reinforces encouraged behaviors and norms
72
+ that can help avoid conflicts and minimize harm.
73
73
 
74
- When an incident does occur, it is important to report it promptly. To report a
75
- possible violation, create a [private security advisory][advisory] — violations
76
- of this code of conduct are considered security vulnerabilities.
74
+ When an incident does occur, it is important to report it promptly. To report
75
+ a possible violation, create a [private security advisory][advisory]
76
+ — violations of this code of conduct are considered security vulnerabilities.
77
77
 
78
78
  Community Moderators take reports of violations seriously and will make every
79
- effort to respond in a timely manner. They will investigate all reports of code
80
- of conduct violations, reviewing messages, logs, and recordings, or interviewing
81
- witnesses and other participants. Community Moderators will keep investigation
82
- and enforcement actions as transparent as possible while prioritizing safety and
83
- confidentiality. In order to honor these values, enforcement actions are carried
84
- out in private with the involved parties, but communicating to the whole
85
- community may be part of a mutually agreed upon resolution.
79
+ effort to respond in a timely manner. They will investigate all reports of
80
+ code of conduct violations, reviewing messages, logs, and recordings, or
81
+ interviewing witnesses and other participants. Community Moderators will keep
82
+ investigation and enforcement actions as transparent as possible while
83
+ prioritizing safety and confidentiality. In order to honor these values,
84
+ enforcement actions are carried out in private with the involved parties, but
85
+ communicating to the whole community may be part of a mutually agreed upon
86
+ resolution.
86
87
 
87
88
  ## Addressing and Repairing Harm
88
89
 
89
- If an investigation by the Community Moderators finds that this Code of Conduct
90
- has been violated, the following enforcement ladder may be used to determine how
91
- best to repair harm, based on the incident's impact on the individuals involved
92
- and the community as a whole. Depending on the severity of a violation, lower
93
- rungs on the ladder may be skipped.
90
+ If an investigation by the Community Moderators finds that this Code of
91
+ Conduct has been violated, the following enforcement ladder may be used to
92
+ determine how best to repair harm, based on the incident's impact on the
93
+ individuals involved and the community as a whole. Depending on the severity
94
+ of a violation, lower rungs on the ladder may be skipped.
94
95
 
95
96
  1. Warning
96
97
  1. Event: A violation involving a single incident or series of incidents.
@@ -104,30 +105,30 @@ rungs on the ladder may be skipped.
104
105
  warning, or the first incidence of a more serious violation.
105
106
  2. Consequence: A private, written warning with a time-limited cooldown
106
107
  period designed to underscore the seriousness of the situation and give
107
- the community members involved time to process the incident. The cooldown
108
- period may be limited to particular communication channels or interactions
109
- with particular community members.
108
+ the community members involved time to process the incident. The
109
+ cooldown period may be limited to particular communication channels or
110
+ interactions with particular community members.
110
111
  3. Repair: Examples of repair may include making an apology, using the
111
112
  cooldown period to reflect on actions and impact, and being thoughtful
112
113
  about re-entering community spaces after the period is over.
113
114
 
114
115
  3. Temporary Suspension
115
- 1. Event: A pattern of repeated violation which the Community Moderators have
116
- tried to address with warnings, or a single serious violation.
116
+ 1. Event: A pattern of repeated violation which the Community Moderators
117
+ have tried to address with warnings, or a single serious violation.
117
118
  2. Consequence: A private written warning with conditions for return from
118
119
  suspension. In general, temporary suspensions give the person being
119
120
  suspended time to reflect upon their behavior and possible corrective
120
121
  actions.
121
122
  3. Repair: Examples of repair include respecting the spirit of the
122
123
  suspension, meeting the specified conditions for return, and being
123
- thoughtful about how to reintegrate with the community when the suspension
124
- is lifted.
124
+ thoughtful about how to reintegrate with the community when the
125
+ suspension is lifted.
125
126
 
126
127
  4. Permanent Ban
127
128
  1. Event: A pattern of repeated code of conduct violations that other steps
128
129
  on the ladder have failed to resolve, or a violation so serious that the
129
- Community Moderators determine there is no way to keep the community safe
130
- with this person as a member.
130
+ Community Moderators determine there is no way to keep the community
131
+ safe with this person as a member.
131
132
  2. Consequence: Access to all community spaces, tools, and communication
132
133
  channels is removed. In general, permanent bans should be rarely used,
133
134
  should have strong reasoning behind them, and should only be resorted to
@@ -140,11 +141,11 @@ with the best interests of our community.
140
141
 
141
142
  ## Scope
142
143
 
143
- This Code of Conduct applies within all community spaces, and also applies when
144
- an individual is officially representing the community in public or other
144
+ This Code of Conduct applies within all community spaces, and also applies
145
+ when an individual is officially representing the community in public or other
145
146
  spaces. Examples of representing our community include using an official email
146
- address, posting via an official social media account, or acting as an appointed
147
- representative at an online or offline event.
147
+ address, posting via an official social media account, or acting as an
148
+ appointed representative at an online or offline event.
148
149
 
149
150
  ## Attribution
150
151
 
@@ -157,8 +158,8 @@ licensed under CC BY-SA 4.0. To view a copy of this license, visit
157
158
 
158
159
  For answers to common questions about Contributor Covenant, see the FAQ at
159
160
  <https://www.contributor-covenant.org/faq>. Translations are provided at
160
- <https://www.contributor-covenant.org/translations>. Additional enforcement and
161
- community guideline resources can be found at
161
+ <https://www.contributor-covenant.org/translations>. Additional enforcement
162
+ and community guideline resources can be found at
162
163
  <https://www.contributor-covenant.org/resources>. The enforcement ladder was
163
164
  inspired by the work of [Mozilla’s code of conduct team][inclusion].
164
165
 
data/CONTRIBUTING.md CHANGED
@@ -1,7 +1,7 @@
1
1
  # Contributing
2
2
 
3
- Contribution to hoe-halostatue is encouraged: bug reports, feature requests, or
4
- code contributions. New features should be proposed and discussed in an
3
+ Contribution to hoe-halostatue is encouraged: bug reports, feature requests,
4
+ or code contributions. New features should be proposed and discussed in an
5
5
  [issue][issues].
6
6
 
7
7
  Before contributing patches, please read the [Licence](./LICENCE.md).
@@ -16,25 +16,25 @@ I have several guidelines to contributing code through pull requests:
16
16
  - All code changes require tests. In most cases, this will be added or updated
17
17
  unit tests. I use [Minitest][minitest].
18
18
 
19
- - I use code formatters, static analysis tools, and linting to ensure consistent
20
- styles and formatting. There should be no warning output from test run
21
- processes. I use [Standard Ruby][standardrb].
19
+ - I use code formatters, static analysis tools, and linting to ensure
20
+ consistent styles and formatting. There should be no warning output from
21
+ test run processes. I use [Standard Ruby][standardrb].
22
22
 
23
- - Proposed changes should be on a thoughtfully-named topic branch and organized
24
- into logical commit chunks as appropriate.
23
+ - Proposed changes should be on a thoughtfully-named topic branch and
24
+ organized into logical commit chunks as appropriate.
25
25
 
26
26
  - Use [Conventional Commits][conventional] with my
27
27
  [conventions](#commit-conventions).
28
28
 
29
- - Versions must not be updated in pull requests unless otherwise directed. This
30
- means that you must not:
29
+ - Versions must not be updated in pull requests unless otherwise directed.
30
+ This means that you must not:
31
31
 
32
32
  - Modify `VERSION` in `lib/hoe/halostatue/version.rb`. When your patch is
33
33
  accepted and a release is made, the version will be updated at that point.
34
34
 
35
35
  - Modify `hoe-halostatue.gemspec`; it is a generated file. (You _may_ use
36
- `rake gemspec` to regenerate it if your change involves metadata related to
37
- gem itself).
36
+ `rake gemspec` to regenerate it if your change involves metadata related
37
+ to gem itself).
38
38
 
39
39
  - Modify the `Gemfile`.
40
40
 
@@ -49,18 +49,19 @@ I have several guidelines to contributing code through pull requests:
49
49
  `CHANGELOG.md` as a separate commit from your main change. (Follow the style
50
50
  in the `CHANGELOG.md` and provide a link to your PR.)
51
51
 
52
- - Include your DCO sign-off in each commit message (see [LICENCE](LICENCE.md)).
52
+ - Include your DCO sign-off in each commit message (see
53
+ [LICENCE](LICENCE.md)).
53
54
 
54
55
  ## AI Contribution Policy
55
56
 
56
- hoe-halostatue is a library of intentional decisions (some of them possibly even
57
- wrong). It is extremely important that contributions of any sort be well
57
+ hoe-halostatue is a library of intentional decisions (some of them possibly
58
+ even wrong). It is extremely important that contributions of any sort be well
58
59
  understood by the submitter and that the developer can attest to the
59
60
  [Developer Certificate of Origin][dco] for each pull request (see
60
61
  [LICENCE](LICENCE.md)).
61
62
 
62
- Any contribution (bug, feature request, or pull request) that uses undeclared AI
63
- output will be rejected.
63
+ Any contribution (bug, feature request, or pull request) that uses undeclared
64
+ AI output will be rejected.
64
65
 
65
66
  ## Test Dependencies
66
67
 
@@ -98,18 +99,18 @@ required metadata trailers are:
98
99
  - `Breaking-Change`: if the change is a breaking change. **Do not** use the
99
100
  shorthand form (`feat!(scope)`) or `BREAKING CHANGE`.
100
101
 
101
- - `Signed-off-by`: this is required for all developers except me, as outlined in
102
- the [Licence](./LICENCE.md#developer-certificate-of-origin).
102
+ - `Signed-off-by`: this is required for all developers except me, as outlined
103
+ in the [Licence](./LICENCE.md#developer-certificate-of-origin).
103
104
 
104
105
  - `Fixes` or `Resolves`: If a change fixes one or more open [issues][issues],
105
106
  that issue must be included in the `Fixes` or `Resolves` trailer. Multiple
106
107
  issues should be listed comma separated in the same trailer:
107
- `Fixes: #1, #5, #7`, but _may_ appear in separate trailers. While both `Fixes`
108
- and `Resolves` are synonyms, only _one_ should be used in a given commit or
109
- pull request.
108
+ `Fixes: #1, #5, #7`, but _may_ appear in separate trailers. While both
109
+ `Fixes` and `Resolves` are synonyms, only _one_ should be used in a given
110
+ commit or pull request.
110
111
 
111
- - `Related to`: If a change does not fix an issue, those issue references should
112
- be included in this trailer.
112
+ - `Related to`: If a change does not fix an issue, those issue references
113
+ should be included in this trailer.
113
114
 
114
115
  [cbeams]: https://cbea.ms/git-commit/
115
116
  [cccoc]: ./CODE_OF_CONDUCT.md
data/LICENCE.md CHANGED
@@ -1,39 +1,43 @@
1
1
  # Licence
2
2
 
3
- - SPDX-License-Identifier: [MIT][mit]
3
+ <!-- SPDX-License-Identifier: MIT -->
4
4
 
5
5
  - Copyright 2022-2026 Austin Ziegler.
6
6
 
7
7
  - Portions copyright 2009 John Barnette.
8
8
  - Portions copyright 2011 James Tucker.
9
- - Portions copyright 2020–2025 Make Dalessio.
9
+ - Portions copyright 2020–2025 Mike Dalessio.
10
10
 
11
11
  The software in this repository is made available under the MIT license.
12
12
 
13
+ - SPDX Licence: [MIT][mit]
14
+
13
15
  ## MIT License
14
16
 
15
- Permission is hereby granted, free of charge, to any person obtaining a copy of
16
- this software and associated documentation files (the "Software"), to deal in
17
- the Software without restriction, including without limitation the rights to
18
- use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
19
- the Software, and to permit persons to whom the Software is furnished to do so,
20
- subject to the following conditions:
17
+ Permission is hereby granted, free of charge, to any person obtaining a copy
18
+ of this software and associated documentation files (the "Software"), to deal
19
+ in the Software without restriction, including without limitation the rights
20
+ to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
21
+ copies of the Software, and to permit persons to whom the Software is
22
+ furnished to do so, subject to the following conditions:
21
23
 
22
24
  The above copyright notice and this permission notice shall be included in all
23
25
  copies or substantial portions of the Software.
24
26
 
25
27
  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
26
- IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
27
- FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR
28
- COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
29
- IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
30
- CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
28
+ IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
29
+ FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
30
+ AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
31
+ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
32
+ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
33
+ SOFTWARE.
31
34
 
32
35
  ## Developer Certificate of Origin
33
36
 
34
37
  All contributors **must** certify they are willing and able to provide their
35
- contributions under the terms of this project's licences with the certification
36
- of the [Developer Certificate of Origin (Version 1.1)](licences/dco.txt).
38
+ contributions under the terms of this project's licences with the
39
+ certification of the
40
+ [Developer Certificate of Origin (Version 1.1)](licences/dco.txt).
37
41
 
38
42
  Such certification is provided by ensuring that a `Signed-off-by`
39
43
  [commit trailer][trailer] is present on every commit:
data/README.md CHANGED
@@ -1,10 +1,15 @@
1
1
  # Hoe::Halostatue Meta-Plugin
2
2
 
3
- - home :: <https://github.com/halostatue/halostatue-data/>
4
- - issues :: <https://github.com/halostatue/halostatue-data/issues>
5
- - code :: <https://github.com/halostatue/halostatue-data/>
3
+ [![RubyGems Version](https://img.shields.io/gem/v/hoe-halostatue?style=for-the-badge "Version")](https://rubygems.org/gems/hoe-halostatue)
4
+ [![Coveralls](https://img.shields.io/coverallsCoverage/github/halostatue/hoe-halostatue?style=for-the-badge)](https://coveralls.io/github/halostatue/hoe-halostatue?branch=main)
5
+ [![Build Status](https://img.shields.io/github/actions/workflow/status/halostatue/hoe-halostatue/ci.yml?style=for-the-badge "Build Status")](https://github.com/halostatue/hoe-halostatue/actions/workflows/ci.yml)
6
+ [![MIT](https://img.shields.io/badge/licence-MIT-blue?style=for-the-badge "MIT")](https://github.com/halostatue/hoe-halostatue/blob/main/LICENCE.md)
7
+
8
+ - home :: <https://github.com/halostatue/hoe-halostatue/>
9
+ - issues :: <https://github.com/halostatue/hoe-halostatue/issues>
10
+ - code :: <https://github.com/halostatue/hoe-halostatue/>
6
11
  - changelog ::
7
- <https://github.com/halostatue/halostatue-data/blob/main/CHANGELOG.md>
12
+ <https://github.com/halostatue/hoe-halostatue/blob/main/CHANGELOG.md>
8
13
 
9
14
  ## Description
10
15
 
@@ -35,8 +40,8 @@ end
35
40
  - Improved Markdown support through functionality derived from
36
41
  [`hoe-markdown`][hmd].
37
42
 
38
- - Improved manual release support by adding a display checklist as a reminder of
39
- tasks frequently forgotten, inspired by [`hoe-doofus`][hd].
43
+ - Improved manual release support by adding a display checklist as a reminder
44
+ of tasks frequently forgotten, inspired by [`hoe-doofus`][hd].
40
45
 
41
46
  - Improved support of automated releases and reproducible builds by
42
47
  incorporating modified versions of [`hoe-git2`][hg2] and
@@ -45,12 +50,12 @@ end
45
50
  ### Improved Metadata URL Parsing
46
51
 
47
52
  Hoe::Halostatue provides an improved implementation for `Hoe#parse_urls`. The
48
- expected format is more or less the same, but accepts any left-aligned unordered
49
- Markdown list (beginning with `-`, `+`, or `*`) and handles lists that wrap
50
- lines (such as the `changelog` entry at the top of this file).
53
+ expected format is more or less the same, but accepts any left-aligned
54
+ unordered Markdown list (beginning with `-`, `+`, or `*`) and handles lists
55
+ that wrap lines (such as the `changelog` entry at the top of this file).
51
56
 
52
- It is more strict than the default `Hoe#parse_urls` because it only accepts the
53
- known aliases for the various RubyGems URI meta keys.
57
+ It is more strict than the default `Hoe#parse_urls` because it only accepts
58
+ the known aliases for the various RubyGems URI meta keys.
54
59
 
55
60
  | RubyGems URI Meta Key | Alias |
56
61
  | --------------------- | ----------------------------------------- |
@@ -71,8 +76,8 @@ Hoe was originally written before Markdown support was pervasive in software
71
76
  forges and before RubyDocs supported Markdown rendering. It assumes that your
72
77
  README is `README.txt` and that your changelog file is `History.txt`.
73
78
 
74
- As a maintainer, you need to opt out of this — unless you use `hoe-markdown` or
75
- Hoe::Halostatue, which allows you to remove this modification from your
79
+ As a maintainer, you need to opt out of this — unless you use `hoe-markdown`
80
+ or Hoe::Halostatue, which allows you to remove this modification from your
76
81
  `Rakefile`:
77
82
 
78
83
  ```ruby
@@ -101,8 +106,8 @@ over `HISTORY`, and exact matches are preferred over case-insensitive matches.
101
106
  #### Automatically Link to GitHub
102
107
 
103
108
  A rake task `markdown:linkify` is created that automatically converts GitHub
104
- references to hyperlinks in your Markdown files and bare hyperlinks to readable
105
- links.
109
+ references to hyperlinks in your Markdown files and bare hyperlinks to
110
+ readable links.
106
111
 
107
112
  | Input | Output |
108
113
  | ----------------------------------------------- | ----------------------------------------------------------------- |
@@ -132,8 +137,8 @@ Query parameters and fragments are preserved in the link URL:
132
137
 
133
138
  > [!NOTE]
134
139
  >
135
- > If `spec.metadata["bug_tracker_uri"]` points to a GitHub repo, link labels to
136
- > that repo are shortened:
140
+ > If `spec.metadata["bug_tracker_uri"]` points to a GitHub repo, link labels
141
+ > to that repo are shortened:
137
142
  >
138
143
  > | Input | Output Link Text |
139
144
  > | ----------------------------------------------------------- | -------------------------- |
@@ -207,8 +212,8 @@ All Markdown files in your `Manifest.txt` will be processed by
207
212
 
208
213
  This will exclude any link found in files in the `licenses/` directory.
209
214
 
210
- - `spec.markdown_linkify_style` (default `:reference`): The style for producing
211
- links. Valid values are:
215
+ - `spec.markdown_linkify_style` (default `:reference`): The style for
216
+ producing links. Valid values are:
212
217
 
213
218
  - `:reference`, which will produce named reference links (e.g.,
214
219
  `[#123][gh-issue-123]`)
@@ -220,10 +225,10 @@ All Markdown files in your `Manifest.txt` will be processed by
220
225
  moved, but new definitions will be appended to the end of the file.
221
226
 
222
227
  - `spec.markdown_linkify_uri_prefixes` (default `nil`): Controls whether
223
- shortened URIs for the current repository have prefixes added to them. This is
224
- either falsy (no prefixes added), `true` default prefixes are added, or a map
225
- with one or more type (`issue`, `pull`, `discussion`) and the prefix to be
226
- applied. The default prefixes (when `true`) are
228
+ shortened URIs for the current repository have prefixes added to them. This
229
+ is either falsy (no prefixes added), `true` default prefixes are added, or a
230
+ map with one or more type (`issue`, `pull`, `discussion`) and the prefix to
231
+ be applied. The default prefixes (when `true`) are
227
232
  `{issue: 'issue', pull: 'pull', discussion: 'discussion'}`.
228
233
 
229
234
  Examples (assuming `true`):
@@ -236,11 +241,11 @@ All Markdown files in your `Manifest.txt` will be processed by
236
241
 
237
242
  ### Automated Release Support
238
243
 
239
- Certain features offered by Hoe plugins are useful for manual releases but work
240
- against automated releases (see [trusted publishing][tp]).
244
+ Certain features offered by Hoe plugins are useful for manual releases but
245
+ work against automated releases (see [trusted publishing][tp]).
241
246
 
242
- - The checklist feature will be disabled when trusted publishing is turned on or
243
- the checklist is unset or empty.
247
+ - The checklist feature will be disabled when trusted publishing is turned on
248
+ or the checklist is unset or empty.
244
249
 
245
250
  - Automatic release tagging is enabled by default, but may be disabled when
246
251
  using release triggers like [release-please][rp].
@@ -260,16 +265,16 @@ end
260
265
 
261
266
  ### Release Checklist (from `hoe-doofus`)
262
267
 
263
- The release checklist feature has been incorporated from `hoe-doofus`, described
264
- as:
268
+ The release checklist feature has been incorporated from `hoe-doofus`,
269
+ described as:
265
270
 
266
271
  > A Hoe plugin that helps me (and you, maybe?) keep from messing up gem
267
272
  > releases. It shows a configurable checklist when `rake release` is run, and
268
273
  > provides a chance to abort if anything's been forgotten.
269
274
 
270
- The current checklist can be seen by running `rake checklist` and the checklist
271
- may be set by using `self.checklist << "new item"` in your spec. If the
272
- checklist is `nil` or empty, the checklist prompt will not be displayed.
275
+ The current checklist can be seen by running `rake checklist` and the
276
+ checklist may be set by using `self.checklist << "new item"` in your spec. If
277
+ the checklist is `nil` or empty, the checklist prompt will not be displayed.
273
278
 
274
279
  ```ruby
275
280
  Hoe.plugin :halostatue
@@ -288,8 +293,8 @@ workflow.
288
293
 
289
294
  ### Git Integration Tasks (from `hoe-git2`)
290
295
 
291
- If Hoe::Halostatue cannot see that it is in a `.git` repository, these features
292
- will be deactivated.
296
+ If Hoe::Halostatue cannot see that it is in a `.git` repository, these
297
+ features will be deactivated.
293
298
 
294
299
  #### Generating the Manifest
295
300
 
@@ -304,15 +309,15 @@ files present. After the release is published, a Git tag will be created and
304
309
  pushed to your repo remotes. Both `$PRERELEASE` and `$PRE` tags are supported,
305
310
  with `$PRERELEASE` taking precedence over `$PRE`, just as with Hoe itself.
306
311
 
307
- In the following example with no other configuration, a `v1.0.0.beta.1` tag will
308
- be created and pushed to the `origin` remote.
312
+ In the following example with no other configuration, a `v1.0.0.beta.1` tag
313
+ will be created and pushed to the `origin` remote.
309
314
 
310
315
  ```console
311
316
  $ rake git:tag VERSION=1.0.0 PRERELEASE=beta.1
312
317
  ```
313
318
 
314
- The tag prefix can be set with `self.git_release_tag_prefix`, which defaults to
315
- `v`.
319
+ The tag prefix can be set with `self.git_release_tag_prefix`, which defaults
320
+ to `v`.
316
321
 
317
322
  The created tag can be pushed to different remotes with `self.git_remotes`,
318
323
  which defaults to `["origin"]`.
@@ -327,50 +332,50 @@ $ rake release VERSION=1.0.0 PRERELEASE=beta.1
327
332
 
328
333
  Support for generating the CHANGELOG from the git commit messages has not been
329
334
  incorporated into Hoe::Halostatue. There are better tools for producing a
330
- changelog automatically (such as [changie][cg] or [cocogitto][cc]), and I prefer
331
- to manage my changelogs by hand.
335
+ changelog automatically (such as [changie][cg] or [cocogitto][cc]), and I
336
+ prefer to manage my changelogs by hand.
332
337
 
333
338
  Listing the applied tags is better done with `git tag`.
334
339
 
335
340
  ### Regenerating the Gem Spec (from `hoe-gemspec2`)
336
341
 
337
342
  The ability to regenerate the gem specification using `rake gemspec` has been
338
- added from `hoe-gemspec2`. This variant adds support for reproducible builds to
339
- the spec generation.
343
+ added from `hoe-gemspec2`. This variant adds support for reproducible builds
344
+ to the spec generation.
340
345
 
341
- Note that `rake gemspec:full` has been removed; there is no support for RubyGems
342
- `signing_key` and `cert_chain`.
346
+ Note that `rake gemspec:full` has been removed; there is no support for
347
+ RubyGems `signing_key` and `cert_chain`.
343
348
 
344
349
  #### Reproducible Build Support
345
350
 
346
351
  > [!NOTE]
347
352
  >
348
353
  > Documentation on reproducible builds in RubyGems is fairly thin, but this
349
- > amounts to having a fixed date set for the specification `date`, which is also
350
- > used to ensure that all files have the same date.
354
+ > amounts to having a fixed date set for the specification `date`, which is
355
+ > also used to ensure that all files have the same date.
351
356
 
352
357
  Reproducible builds are primarily performed by setting the value of
353
- `$SOURCE_DATE_EPOCH`. If unset, RubyGems will use a fixed date (1980-01-02), but
354
- only when building the gem.
358
+ `$SOURCE_DATE_EPOCH`. If unset, RubyGems will use a fixed date (1980-01-02),
359
+ but only when building the gem.
355
360
 
356
- The Hoe::Halostatue implementation of the `gemspec` task will set the generated
357
- specification date and `$SOURCE_DATE_EPOCH` for proper handling by the RubyGems
358
- build process.
361
+ The Hoe::Halostatue implementation of the `gemspec` task will set the
362
+ generated specification date and `$SOURCE_DATE_EPOCH` for proper handling by
363
+ the RubyGems build process.
359
364
 
360
365
  > [!IMPORTANT]
361
366
  >
362
367
  > Most projects will use the default reproducible builds behaviour and should
363
- > not have `$SOURCE_DATE_EPOCH` set when publishing releases (either manually or
364
- > in CI environments).
368
+ > not have `$SOURCE_DATE_EPOCH` set when publishing releases (either manually
369
+ > or in CI environments).
365
370
 
366
371
  For other cases, `$SOURCE_DATE_EPOCH` is used if it is set, or behaviour is
367
372
  controlled by the `spec.reproducible_gemspec` option.
368
373
 
369
- - `:default` / `true`: uses the default RubyGems behaviour, setting the date to
370
- `1980-01-02`
374
+ - `:default` / `true`: uses the default RubyGems behaviour, setting the date
375
+ to `1980-01-02`
371
376
 
372
- - `:current`: uses the date in the current gem `gemspec` file, or falls back to
373
- the default RubyGems behaviour
377
+ - `:current`: uses the date in the current gem `gemspec` file, or falls back
378
+ to the default RubyGems behaviour
374
379
 
375
380
  - `false`: disables reproducible builds as much as possible
376
381
 
@@ -383,13 +388,13 @@ The default `spec.reproducible_gemspec` value is `:default`.
383
388
 
384
389
  > [!IMPORTANT]
385
390
  >
386
- > Trusted releases should only be enabled when using a [trusted publishing][tp]
387
- > workflow. It is strongly recommended that all gem releases be performed with
388
- > such a workflow.
391
+ > Trusted releases should only be enabled when using a
392
+ > [trusted publishing][tp] workflow. It is strongly recommended that all gem
393
+ > releases be performed with such a workflow.
389
394
 
390
- If `spec.trusted_release` is set to `true` changes will be made to the `release`
391
- workflow. It will bypass certain manual release protections offered by Hoe and
392
- Hoe::Halostatue:
395
+ If `spec.trusted_release` is set to `true` changes will be made to the
396
+ `release` workflow. It will bypass certain manual release protections offered
397
+ by Hoe and Hoe::Halostatue:
393
398
 
394
399
  - The version discovered by Hoe will be trusted as correct, removing the need
395
400
  for specifying the version.
@@ -398,9 +403,9 @@ Hoe::Halostatue:
398
403
 
399
404
  ### Strict Deprecation Warnings
400
405
 
401
- Deprecation warnings signal code that will break in future Ruby or gem versions.
402
- Making warnings strict during tests catches these issues early, before they
403
- reach production or complicate upgrades.
406
+ Deprecation warnings signal code that will break in future Ruby or gem
407
+ versions. Making warnings strict during tests catches these issues early,
408
+ before they reach production or complicate upgrades.
404
409
 
405
410
  Warnings can be made strict (an exception will be thrown) for tests by adding
406
411
  the following to your test or spec helper file (`test/minitest_helper.rb` or
data/SECURITY.md CHANGED
@@ -2,8 +2,8 @@
2
2
 
3
3
  ## LLM-Generated Security Report Policy
4
4
 
5
- Absolutely no security reports will be accepted that have been generated by LLM
6
- agents.
5
+ Absolutely no security reports will be accepted that have been generated
6
+ solely by LLM agents. There must be a human that confirms the issue.
7
7
 
8
8
  ## Supported Versions
9
9
 
data/lib/hoe/halostatue/gemspec.rb CHANGED
@@ -1,5 +1,7 @@
1
1
  # frozen_string_literal: true
2
2
 
3
+ require "date"
4
+
3
5
  module Hoe::Halostatue::Gemspec
4
6
  # Whether a fixed date should be used for reproducible gemspec values. This is ignored
5
7
  # if `$SOURCE_DATE_EPOCH` is set. Acceptable values are:
@@ -16,8 +18,8 @@ module Hoe::Halostatue::Gemspec
16
18
 
17
19
  LINKS = /\[(?<name>.+?)\](?:\(.+?\)|\[.+?\])/ # :nodoc:
18
20
  PERMITTED_CLASSES = [ # :nodoc:
19
- Symbol, Time, Date, Gem::Dependency, Gem::Platform, Gem::Requirement,
20
- Gem::Specification, Gem::Version, Gem::Version::Requirement
21
+ ::Symbol, ::Time, ::Date, ::Gem::Dependency, ::Gem::Platform, ::Gem::Requirement,
22
+ ::Gem::Specification, ::Gem::Version, ::Gem::Version::Requirement
21
23
  ].freeze
22
24
  PERMITTED_SYMBOLS = %i[development runtime].freeze # :nodoc:
23
25
 
data/lib/hoe/halostatue/git.rb CHANGED
@@ -42,7 +42,7 @@ module Hoe::Halostatue::Git
42
42
  tag = ENV["TAG"]
43
43
  ver = ENV["VERSION"] || version
44
44
  pre = ENV["PRERELEASE"] || ENV["PRE"]
45
- ver += ".#{pre}" if pre && !ver.ends_with?(pre)
45
+ ver += ".#{pre}" if pre && !ver.end_with?(pre)
46
46
  tag ||= "#{git_release_tag_prefix}#{ver}"
47
47
 
48
48
  git_tag_and_push tag
data/lib/hoe/halostatue/version.rb CHANGED
@@ -1,5 +1,5 @@
1
1
  # frozen_string_literal: true
2
2
 
3
3
  module Hoe::Halostatue
4
- VERSION = "3.0.0" # :nodoc:
4
+ VERSION = "3.0.2" # :nodoc:
5
5
  end
metadata CHANGED
@@ -1,7 +1,7 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: hoe-halostatue
3
3
  version: !ruby/object:Gem::Version
4
- version: 3.0.0
4
+ version: 3.0.2
5
5
  platform: ruby
6
6
  authors:
7
7
  - Austin Ziegler
@@ -175,7 +175,7 @@ dependencies:
175
175
  - - "~>"
176
176
  - !ruby/object:Gem::Version
177
177
  version: '1.50'
178
- description: |-
178
+ description: |
179
179
  Hoe::Halostatue is a [Hoe][hoe] meta-plugin that provides improved support for
180
180
  Markdown README files, provides features from other plugins, and enables
181
181
  improved support for [trusted publishing][tp].
@@ -183,6 +183,8 @@ description: |-
183
183
  Hoe::Halostatue 3.0 incorporates functionality derived from
184
184
  [`hoe-gemspec2`][hgs2] with more support for [reproducible builds][rb] and
185
185
  replaces [`hoe-markdown`][hmd] with an internal implementation.
186
+
187
+ ==== To Install:
186
188
  email:
187
189
  - halostatue@gmail.com
188
190
  executables: []
@@ -193,7 +195,6 @@ extra_rdoc_files:
193
195
  - CONTRIBUTING.md
194
196
  - CONTRIBUTORS.md
195
197
  - LICENCE.md
196
- - Manifest.txt
197
198
  - README.md
198
199
  - SECURITY.md
199
200
  - licences/dco.txt
@@ -218,14 +219,14 @@ files:
218
219
  - licences/dco.txt
219
220
  - test/hoe/halostatue/markdown/test_linkify.rb
220
221
  - test/minitest_helper.rb
221
- homepage: https://github.com/halostatue/halostatue-data/
222
+ homepage: https://github.com/halostatue/hoe-halostatue/
222
223
  licenses:
223
224
  - MIT
224
225
  metadata:
225
- homepage_uri: https://github.com/halostatue/halostatue-data/
226
- bug_tracker_uri: https://github.com/halostatue/halostatue-data/issues
227
- source_code_uri: https://github.com/halostatue/halostatue-data/
228
- changelog_uri: https://github.com/halostatue/halostatue-data/blob/main/CHANGELOG.md
226
+ homepage_uri: https://github.com/halostatue/hoe-halostatue/
227
+ bug_tracker_uri: https://github.com/halostatue/hoe-halostatue/issues
228
+ source_code_uri: https://github.com/halostatue/hoe-halostatue/
229
+ changelog_uri: https://github.com/halostatue/hoe-halostatue/blob/main/CHANGELOG.md
229
230
  rubygems_mfa_required: 'true'
230
231
  rdoc_options:
231
232
  - "--main"
@@ -243,7 +244,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
243
244
  - !ruby/object:Gem::Version
244
245
  version: '0'
245
246
  requirements: []
246
- rubygems_version: 4.0.4
247
+ rubygems_version: 4.0.20
247
248
  specification_version: 4
248
249
  summary: Hoe::Halostatue is a [Hoe][hoe] meta-plugin that provides improved support
249
250
  for Markdown README files, provides features from other plugins, and enables improved