@@ -143,7 +143,10 @@ become out of date. Start by building and testing a released version
143
143
of RipMe and then ensure that any changes you make do not cause more
144
144
tests to break.
145
145
146
- # releasing
146
+ # Publishing a New Release
147
+
148
+ ## Create the Release
149
+
147
150
edit draft release ` develop build main ` the following way:
148
151
1 . create a new tag with version from ripme filename, e.g. 2.1.12-7-d0b97acd
149
152
1 . set the title to same name
@@ -152,8 +155,24 @@ edit draft release `develop build main` the following way:
152
155
1 . edit release text as appropriate
153
156
1 . save
154
157
158
+ Another version of instructions that worked for @metaprime :
159
+ - Push latest-main to the version you will want to publish, and wait a few minutes for automation to finish running the build
160
+ - Go to https://github.com/RipMeApp/ripme/releases
161
+ - Find development build main
162
+ - Click the "Edit" button
163
+ - Note the version in the filename for the .jar
164
+ - Push a tag with that version number
165
+ - Update the tag on the release to that version numbered tag that matches the .jar's name
166
+ - Change the title on the release to match
167
+ - Uncheck "set as a pre-release"
168
+ - Check "set as the latest release"
169
+ - Click "publish release"
170
+
171
+ ## Publish the JSON update so the update check will pick up the new release
172
+
155
173
then, prepare the repo for update check, and next release:
156
174
1 . edit ripme.json, enter new hash, version and short description, and commit
175
+ 1 . Get the hash by downloading the file and computing a sha256 hash
157
176
1 . set the base tag for next release verison calculation, e.g. 2.1.13 on this commit
158
177
1 . push tag and commit
159
178
1 . remove old base tag, not needed any more, e.g. 2.1.12
0 commit comments