jeweler 2.1.2 → 2.2.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.semver +2 -2
- data/.travis.yml +2 -4
- data/ChangeLog.markdown +3 -0
- data/Gemfile +1 -0
- data/Gemfile.lock +12 -8
- data/README.org +375 -0
- data/Rakefile +1 -2
- data/jeweler.gemspec +60 -57
- metadata +20 -7
- data/Gemfile.orig +0 -54
- data/Rakefile.orig +0 -88
- data/jeweler.gemspec.orig +0 -464
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 8c47c5eda7696e69db59a88eff4af831c67757fd
|
4
|
+
data.tar.gz: 98f650076b291ba872f9600fe984df47e55da57c
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 262606cb12580564221b5f80c1e18565d2aac1d8562a186aa8275621341917fe8d394d0229514226d15db6295de0d5282e29176ef21ddbb2d1f9bac08e98f78f
|
7
|
+
data.tar.gz: e36802e7601e774a82fc0513043f4e1db187ab1be8288e3d9d751317087865e0ad16c6dec07afed4b2eaf122df7d16919b766dc2c86f127186bacea9c6c7d583
|
data/.semver
CHANGED
data/.travis.yml
CHANGED
@@ -2,10 +2,8 @@ language: ruby
|
|
2
2
|
before_install: 'gem update bundler'
|
3
3
|
install: 'bundle install --jobs=3 --retry=3' # Suppress the --deployment flag'
|
4
4
|
rvm:
|
5
|
-
-
|
6
|
-
- 2.0.0
|
7
|
-
- 2.1.0
|
8
|
-
- 2.2.0
|
5
|
+
- 2.2.2
|
9
6
|
- 2.3.0
|
7
|
+
- 2.3.1
|
10
8
|
notifications:
|
11
9
|
irc: "irc.freenode.org#jeweler"
|
data/ChangeLog.markdown
CHANGED
data/Gemfile
CHANGED
data/Gemfile.lock
CHANGED
@@ -1,13 +1,14 @@
|
|
1
1
|
PATH
|
2
2
|
remote: .
|
3
3
|
specs:
|
4
|
-
jeweler (2.1
|
4
|
+
jeweler (2.2.1)
|
5
5
|
builder
|
6
6
|
bundler (>= 1.0)
|
7
7
|
git (>= 1.2.5)
|
8
8
|
github_api (~> 0.11.0)
|
9
9
|
highline (>= 1.6.15)
|
10
10
|
nokogiri (>= 1.5.10)
|
11
|
+
psych (~> 2.2)
|
11
12
|
rake
|
12
13
|
rdoc
|
13
14
|
semver
|
@@ -18,7 +19,8 @@ GEM
|
|
18
19
|
activesupport (3.2.22.5)
|
19
20
|
i18n (~> 0.6, >= 0.6.4)
|
20
21
|
multi_json (~> 1.0)
|
21
|
-
addressable (2.
|
22
|
+
addressable (2.5.0)
|
23
|
+
public_suffix (~> 2.0, >= 2.0.2)
|
22
24
|
bluecloth (2.2.0)
|
23
25
|
builder (3.2.2)
|
24
26
|
coveralls (0.8.15)
|
@@ -57,7 +59,7 @@ GEM
|
|
57
59
|
hashie (3.4.6)
|
58
60
|
highline (1.7.8)
|
59
61
|
i18n (0.7.0)
|
60
|
-
json (
|
62
|
+
json (2.0.2)
|
61
63
|
jwt (1.5.6)
|
62
64
|
metaclass (0.0.4)
|
63
65
|
mhennemeyer-output_catcher (1.0.1)
|
@@ -77,17 +79,18 @@ GEM
|
|
77
79
|
multi_xml (~> 0.5)
|
78
80
|
rack (>= 1.2, < 3)
|
79
81
|
power_assert (0.3.1)
|
82
|
+
psych (2.2.0)
|
83
|
+
public_suffix (2.0.4)
|
80
84
|
rack (2.0.1)
|
81
85
|
rake (11.3.0)
|
82
|
-
rdoc (
|
83
|
-
json (~> 1.4)
|
86
|
+
rdoc (5.0.0)
|
84
87
|
redgreen (1.2.2)
|
85
88
|
rr (1.2.0)
|
86
89
|
semver (1.0.1)
|
87
90
|
shoulda (3.5.0)
|
88
91
|
shoulda-context (~> 1.0, >= 1.0.1)
|
89
92
|
shoulda-matchers (>= 1.4.1, < 3.0)
|
90
|
-
shoulda-context (1.2.
|
93
|
+
shoulda-context (1.2.2)
|
91
94
|
shoulda-matchers (2.8.0)
|
92
95
|
activesupport (>= 3.0.0)
|
93
96
|
simplecov (0.12.0)
|
@@ -97,7 +100,7 @@ GEM
|
|
97
100
|
simplecov-html (0.10.0)
|
98
101
|
term-ansicolor (1.4.0)
|
99
102
|
tins (~> 1.0)
|
100
|
-
test-unit (3.2.
|
103
|
+
test-unit (3.2.2)
|
101
104
|
power_assert
|
102
105
|
test-unit-rr (1.0.5)
|
103
106
|
rr (>= 1.1.1)
|
@@ -126,6 +129,7 @@ DEPENDENCIES
|
|
126
129
|
mhennemeyer-output_catcher
|
127
130
|
mocha
|
128
131
|
nokogiri (>= 1.5.10)
|
132
|
+
psych (~> 2.2)
|
129
133
|
rake
|
130
134
|
rdoc
|
131
135
|
redgreen
|
@@ -139,4 +143,4 @@ DEPENDENCIES
|
|
139
143
|
yard (>= 0.8.5)
|
140
144
|
|
141
145
|
BUNDLED WITH
|
142
|
-
1.
|
146
|
+
1.13.6
|
data/README.org
ADDED
@@ -0,0 +1,375 @@
|
|
1
|
+
/Jeweler maintenance has now shifted to Fred Mitchell/. I am now
|
2
|
+
maintaining both Jeweler and its fork, juwelier. I will keep Jeweler at
|
3
|
+
least functional with the latest Ruby releases, but put new features in
|
4
|
+
Juwelier. Your input on this is more than welcome.
|
5
|
+
|
6
|
+
* Jeweler: Craft the perfect RubyGem
|
7
|
+
|
8
|
+
[[https://gitter.im/technicalpickles/jeweler?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge][[[https://badges.gitter.im/technicalpickles/jeweler.svg]]]]
|
9
|
+
|
10
|
+
Jeweler provides the noble ruby developer with two primary features:
|
11
|
+
|
12
|
+
- a library for managing and releasing RubyGem projects
|
13
|
+
- a scaffold generator for starting new RubyGem projects
|
14
|
+
|
15
|
+
PLEASE NOTE that if you are starting afresh, please use the successor
|
16
|
+
[[https://github.com/flajann2/juwelier][Juwelier]] I (Fred Mitchell,
|
17
|
+
flajann2) will be maintaining both Jeweler and Juwelier, but will be
|
18
|
+
adding new features to Juwelier, and eventually "merge" this one into
|
19
|
+
Juwelier after some namespace issues are dealt with.
|
20
|
+
|
21
|
+
[[https://travis-ci.org/technicalpickles/jeweler][[[https://travis-ci.org/technicalpickles/jeweler.png]]]]
|
22
|
+
[[https://coveralls.io/r/technicalpickles/jeweler][[[https://coveralls.io/repos/technicalpickles/jeweler/badge.png]]]]
|
23
|
+
[[https://www.versioneye.com/ruby/jeweler/2.0.0][[[https://www.versioneye.com/ruby/jeweler/2.0.0/badge.png]]]]
|
24
|
+
[[https://codeclimate.com/github/technicalpickles/jeweler][[[https://codeclimate.com/github/technicalpickles/jeweler/badges/gpa.svg]]]]
|
25
|
+
|
26
|
+
** Hello, world
|
27
|
+
|
28
|
+
Use RubyGems to install the heck out of jeweler to get started:
|
29
|
+
|
30
|
+
#+BEGIN_EXAMPLE
|
31
|
+
$ gem install jeweler
|
32
|
+
#+END_EXAMPLE
|
33
|
+
|
34
|
+
With jeweler installed, you can use the =jeweler= command to generate a
|
35
|
+
new project. For the most basic use, just give it a name:
|
36
|
+
|
37
|
+
#+BEGIN_EXAMPLE
|
38
|
+
$ jeweler hello-gem
|
39
|
+
#+END_EXAMPLE
|
40
|
+
|
41
|
+
This requires some Git configuration (like name, email, GitHub account,
|
42
|
+
etc), but =jeweler= will prompt along the way.
|
43
|
+
|
44
|
+
Your new =hello-gem= gem is ready in the =hello-gem= directory. Take a
|
45
|
+
peek, and you'll see several files and directories
|
46
|
+
|
47
|
+
- =Rakefile= setup for jeweler, running tests, generating
|
48
|
+
documentation, and releasing to
|
49
|
+
[[http://rubygems.org/][rubygems.org]]
|
50
|
+
- =README.rdoc= with contribution guidelines and copyright info
|
51
|
+
crediting you
|
52
|
+
- =LICENSE= with the MIT licensed crediting you
|
53
|
+
- =Gemfile= with development dependencies filled in
|
54
|
+
- =lib/hello-gem.rb= waiting for you to code
|
55
|
+
- =test/= containing a (failing) shoulda test suite
|
56
|
+
[[http://github.com/thoughtbot/shoulda][shoulda]]
|
57
|
+
|
58
|
+
*** More =jeweler= options
|
59
|
+
|
60
|
+
The =jeweler= command supports a lot of options. Mostly, they are for
|
61
|
+
generating baked in support for this test framework, or that.
|
62
|
+
|
63
|
+
Check out =jeweler --help= for the most up to date options.
|
64
|
+
|
65
|
+
** Hello, rake tasks
|
66
|
+
|
67
|
+
Beyond just editing source code, you'll be interacting with your gem
|
68
|
+
using =rake= a lot. To see all the tasks available with a brief
|
69
|
+
description, you can run:
|
70
|
+
|
71
|
+
#+BEGIN_EXAMPLE
|
72
|
+
$ rake -T
|
73
|
+
#+END_EXAMPLE
|
74
|
+
|
75
|
+
You'll need a version before you can start installing your gem locally.
|
76
|
+
The easiest way is with the =version:write= Rake task. Let's imagine you
|
77
|
+
start with 0.1.0
|
78
|
+
|
79
|
+
#+BEGIN_EXAMPLE
|
80
|
+
$ rake version:write MAJOR=0 MINOR=1 PATCH=0
|
81
|
+
#+END_EXAMPLE
|
82
|
+
|
83
|
+
You can now go forth and develop, now that there's an initial version
|
84
|
+
defined. Eventually, you should install and test the gem:
|
85
|
+
|
86
|
+
#+BEGIN_EXAMPLE
|
87
|
+
$ rake install
|
88
|
+
#+END_EXAMPLE
|
89
|
+
|
90
|
+
The =install= rake task builds the gem and =gem install=s it. You're all
|
91
|
+
set if you're using [[http://rvm.beginrescueend.com/][RVM]], but you may
|
92
|
+
need to run it with sudo if you have a system-installed ruby:
|
93
|
+
|
94
|
+
#+BEGIN_EXAMPLE
|
95
|
+
$ sudo rake install
|
96
|
+
#+END_EXAMPLE
|
97
|
+
|
98
|
+
*** Releasing
|
99
|
+
|
100
|
+
At last, it's time to [[http://shipitsquirrel.github.com/][ship it]]!
|
101
|
+
Make sure you have everything committed and pushed, then go wild:
|
102
|
+
|
103
|
+
#+BEGIN_EXAMPLE
|
104
|
+
$ rake release
|
105
|
+
#+END_EXAMPLE
|
106
|
+
|
107
|
+
This will automatically:
|
108
|
+
|
109
|
+
- Generate =hello-gem.gemspec= and commit it
|
110
|
+
- Use =git= to tag =v0.1.0= and push it
|
111
|
+
- Build =hello-gem-0.1.0.gem= and push it to
|
112
|
+
[[http://rubygems.org/gems/][rubygems.org]]
|
113
|
+
|
114
|
+
=rake release= accepts REMOTE(default: =origin=), LOCAL\_BRANCH(default:
|
115
|
+
=master=), REMOTE\_BRANCH(default: =master=) and BRANCH(default:
|
116
|
+
master)as options.
|
117
|
+
|
118
|
+
#+BEGIN_EXAMPLE
|
119
|
+
$ rake release REMOTE=upstream LOCAL_BRANCH=critical-security-fix REMOTE_BRANCH=v3
|
120
|
+
#+END_EXAMPLE
|
121
|
+
|
122
|
+
This will tag and push the commits on your local branch named
|
123
|
+
=critical-security-fix= to branch named =v3= in remote named =upstream=
|
124
|
+
(if you have commit rights on =upstream=) and release the gem.
|
125
|
+
|
126
|
+
#+BEGIN_EXAMPLE
|
127
|
+
$ rake release BRANCH=v3
|
128
|
+
#+END_EXAMPLE
|
129
|
+
|
130
|
+
If both remote and local branches are the same, use =BRANCH= option to
|
131
|
+
simplify. This will tag and push the commits on your local branch named
|
132
|
+
=v3= to branch named =v3= in remote named =origin= (if you have commit
|
133
|
+
rights on =origin=) and release the gem.
|
134
|
+
|
135
|
+
*** Version bumping
|
136
|
+
|
137
|
+
It feels good to release code. Do it, do it often. But before that, bump
|
138
|
+
the version. Then release it. There's a few ways to update the version:
|
139
|
+
|
140
|
+
#+BEGIN_EXAMPLE
|
141
|
+
# version:write like before
|
142
|
+
$ rake version:write MAJOR=0 MINOR=3 PATCH=0
|
143
|
+
|
144
|
+
# bump just major, ie 0.1.0 -> 1.0.0
|
145
|
+
$ rake version:bump:major
|
146
|
+
|
147
|
+
# bump just minor, ie 0.1.0 -> 0.2.0
|
148
|
+
$ rake version:bump:minor
|
149
|
+
|
150
|
+
# bump just patch, ie 0.1.0 -> 0.1.1
|
151
|
+
$ rake version:bump:patch
|
152
|
+
#+END_EXAMPLE
|
153
|
+
|
154
|
+
Then it's the same =release= we used before:
|
155
|
+
|
156
|
+
#+BEGIN_EXAMPLE
|
157
|
+
$ rake release
|
158
|
+
#+END_EXAMPLE
|
159
|
+
|
160
|
+
** Customizing your gem
|
161
|
+
|
162
|
+
If you've been following along so far, your gem is just a blank slate.
|
163
|
+
You're going to need to make it colorful and full of metadata.
|
164
|
+
|
165
|
+
You can customize your gem by updating your =Rakefile=. With a newly
|
166
|
+
generated project, it will look something like this:
|
167
|
+
|
168
|
+
#+BEGIN_EXAMPLE
|
169
|
+
require 'jeweler'
|
170
|
+
Jeweler::Tasks.new do |gem|
|
171
|
+
# gem is a Gem::Specification... see http://guides.rubygems.org/specification-reference/ for more options
|
172
|
+
gem.name = "whatwhatwhat"
|
173
|
+
gem.summary = %Q{TODO: one-line summary of your gem}
|
174
|
+
gem.description = %Q{TODO: longer description of your gem}
|
175
|
+
gem.email = "josh@technicalpickles.com"
|
176
|
+
gem.homepage = "http://github.com/technicalpickles/whatwhatwhat"
|
177
|
+
gem.authors = ["Joshua Nichols"]
|
178
|
+
end
|
179
|
+
Jeweler::RubygemsDotOrgTasks.new
|
180
|
+
#+END_EXAMPLE
|
181
|
+
|
182
|
+
It's crucial to understand the =gem= object is just a
|
183
|
+
Gem::Specification. You can read up about it at
|
184
|
+
[[http://guides.rubygems.org/specification-reference/][guides.rubygems.org/specification-reference]].
|
185
|
+
This is the most basic way of specifying a gem, Jeweler-managed or not.
|
186
|
+
Jeweler just exposes this to you, in addition to providing some
|
187
|
+
reasonable defaults, which we'll explore now.
|
188
|
+
|
189
|
+
*** Project information
|
190
|
+
|
191
|
+
#+BEGIN_EXAMPLE
|
192
|
+
gem.name = "whatwhatwhat"
|
193
|
+
#+END_EXAMPLE
|
194
|
+
|
195
|
+
Every gem has a name. Among other things, the gem name is how you are
|
196
|
+
able to =gem install= it.
|
197
|
+
[[http://guides.rubygems.org/specification-reference/#name][Reference]]
|
198
|
+
|
199
|
+
#+BEGIN_EXAMPLE
|
200
|
+
gem.summary = %Q{TODO: one-line summary of your gem}
|
201
|
+
#+END_EXAMPLE
|
202
|
+
|
203
|
+
This is a one line summary of your gem. This is displayed, for example,
|
204
|
+
when you use =gem list --details= or view it on
|
205
|
+
[[http://rubygems.org/gems/][rubygems.org]].
|
206
|
+
|
207
|
+
#+BEGIN_EXAMPLE
|
208
|
+
gem.description = %Q{TODO: longer description of your gem}
|
209
|
+
#+END_EXAMPLE
|
210
|
+
|
211
|
+
Description is a longer description. Scholars ascertain that knowledge
|
212
|
+
of where the description is used was lost centuries ago.
|
213
|
+
|
214
|
+
#+BEGIN_EXAMPLE
|
215
|
+
gem.email = "josh@technicalpickles.com"
|
216
|
+
#+END_EXAMPLE
|
217
|
+
|
218
|
+
This should be a way to get a hold of you regarding the gem.
|
219
|
+
|
220
|
+
#+BEGIN_EXAMPLE
|
221
|
+
gem.homepage = "http://github.com/technicalpickles/whatwhatwhat"
|
222
|
+
#+END_EXAMPLE
|
223
|
+
|
224
|
+
The homepage should have more information about your gem. The jeweler
|
225
|
+
generator guesses this based on the assumption your code lives on
|
226
|
+
[[http://github.com/][GitHub]], using your Git configuration to find
|
227
|
+
your GitHub username. This is displayed by =gem list --details= and on
|
228
|
+
rubygems.org.
|
229
|
+
|
230
|
+
#+BEGIN_EXAMPLE
|
231
|
+
gem.authors = ["Joshua Nichols"]
|
232
|
+
#+END_EXAMPLE
|
233
|
+
|
234
|
+
Hey, this is you, the author (or me in this case). The =jeweler=
|
235
|
+
generator also guesses this from your Git configuration. This is
|
236
|
+
displayed by =gem list --details= and on rubygems.org.
|
237
|
+
|
238
|
+
*** Files
|
239
|
+
|
240
|
+
The quickest way to add more files is to =git add= them. Jeweler uses
|
241
|
+
your Git repository to populate your gem's files by including added and
|
242
|
+
committed and excluding =.gitignore=d. In most cases, this is reasonable
|
243
|
+
enough.
|
244
|
+
|
245
|
+
If you need to tweak the files, that's cool. Jeweler populates
|
246
|
+
=gem.files= as a =Rake::FileList=. It's like a normal array, except you
|
247
|
+
can =include= and =exclude= file globs:
|
248
|
+
|
249
|
+
#+BEGIN_EXAMPLE
|
250
|
+
gem.files.exclude 'tmp' # exclude temporary directory
|
251
|
+
gem.files.include 'lib/foo/bar.rb' # explicitly include lib/foo/bar.rb
|
252
|
+
#+END_EXAMPLE
|
253
|
+
|
254
|
+
If that's not enough, you can just set =gem.files= outright
|
255
|
+
|
256
|
+
#+BEGIN_EXAMPLE
|
257
|
+
gem.files = Dir.glob('lib/**/*.rb')
|
258
|
+
#+END_EXAMPLE
|
259
|
+
|
260
|
+
*** Dependencies
|
261
|
+
|
262
|
+
Dependencies let you define other gems that your gem needs to function.
|
263
|
+
=gem install your-gem= will install your-gem's dependencies along with
|
264
|
+
it, and when you use your-gem in an application, the dependencies will
|
265
|
+
be made available. Use =gem.add_dependency= to register them.
|
266
|
+
[[http://guides.rubygems.org/specification-reference/#add_development_dependency][Reference]]
|
267
|
+
|
268
|
+
#+BEGIN_EXAMPLE
|
269
|
+
gem.add_dependency 'nokogiri'
|
270
|
+
#+END_EXAMPLE
|
271
|
+
|
272
|
+
This will ensure a version of =nokogiri= is installed, but it doesn't
|
273
|
+
require anything more than that. You can provide extra args to be more
|
274
|
+
specific:
|
275
|
+
|
276
|
+
#+BEGIN_EXAMPLE
|
277
|
+
gem.add_dependency 'nokogiri', '= 1.2.1' # exactly version 1.2.1
|
278
|
+
gem.add_dependency 'nokogiri', '>= 1.2.1' # greater than or equal to 1.2.1, ie, 1.2.1, 1.2.2, 1.3.0, 2.0.0, etc
|
279
|
+
gem.add_dependency 'nokogiri', '>= 1.2.1', '< 1.3.0' # greater than or equal to 1.2.1, but less than 1.3.0
|
280
|
+
gem.add_dependency 'nokogiri', '~> 1.2.1' # same thing, but more concise
|
281
|
+
#+END_EXAMPLE
|
282
|
+
|
283
|
+
When specifying which version is required, there's a bit of the
|
284
|
+
condunrum. You want to allow the most versions possible, but you want to
|
285
|
+
be sure they are compatible. Using =>= 1.2.1= is fine most of the time,
|
286
|
+
except until the point that 2.0.0 comes out and totally breaks backwards
|
287
|
+
the API. That's when it's good to use =~> 1.2.1=, which requires any
|
288
|
+
version in the =1.2= family, starting with =1.2.1=.
|
289
|
+
|
290
|
+
*** Executables
|
291
|
+
|
292
|
+
Executables let your gem install shell commands. Just put any executable
|
293
|
+
scripts in the =bin/= directory, make sure they are added using =git=,
|
294
|
+
and Jeweler will take care of the rest.
|
295
|
+
|
296
|
+
When you need more finely grained control over it, you can set it
|
297
|
+
yourself:
|
298
|
+
|
299
|
+
#+BEGIN_EXAMPLE
|
300
|
+
gem.executables = ['foo'] # note, it's the file name relative to `bin/`, not the project root
|
301
|
+
#+END_EXAMPLE
|
302
|
+
|
303
|
+
*** Versioning
|
304
|
+
|
305
|
+
We discussed earlier how to bump the version. The rake tasks are really
|
306
|
+
just convience methods for manipulating the =VERSION= file. It just
|
307
|
+
contains a version string, like =1.2.3=.
|
308
|
+
|
309
|
+
=VERSION= is a convention used by Jeweler, and is used to populate
|
310
|
+
=gem.version=. You can actually set this yourself, and Jeweler won't try
|
311
|
+
to override it:
|
312
|
+
|
313
|
+
#+BEGIN_EXAMPLE
|
314
|
+
gem.version = '1.2.3'
|
315
|
+
#+END_EXAMPLE
|
316
|
+
|
317
|
+
A common pattern is to have this in a version constant in your library.
|
318
|
+
This is convenient, because users of the library can query the version
|
319
|
+
they are using at runtime.
|
320
|
+
|
321
|
+
#+BEGIN_EXAMPLE
|
322
|
+
# in lib/foo/version.rb
|
323
|
+
class Foo
|
324
|
+
module Version
|
325
|
+
MAJOR = 1
|
326
|
+
MINOR = 2
|
327
|
+
PATCH = 3
|
328
|
+
BUILD = 'pre3'
|
329
|
+
|
330
|
+
STRING = [MAJOR, MINOR, PATCH, BUILD].compact.join('.')
|
331
|
+
end
|
332
|
+
end
|
333
|
+
|
334
|
+
# in Rakefile
|
335
|
+
require 'jeweler'
|
336
|
+
require './lib/foo/version.rb'
|
337
|
+
Jeweler::Tasks.new do |gem|
|
338
|
+
# snip
|
339
|
+
gem.version = Foo::Version::STRING
|
340
|
+
end
|
341
|
+
#+END_EXAMPLE
|
342
|
+
|
343
|
+
*** Rake tasks
|
344
|
+
|
345
|
+
Jeweler lives inside of Rake. As a result, they are dear friends. But,
|
346
|
+
that friendship doesn't interfere with typical Rake operations.
|
347
|
+
|
348
|
+
That means you can define your own namespaces, tasks, or use third party
|
349
|
+
Rake libraries without cause for concern.
|
350
|
+
|
351
|
+
** Contributing to Jeweler
|
352
|
+
|
353
|
+
- Check out the latest master to make sure the feature hasn't been
|
354
|
+
implemented or the bug hasn't been fixed yet
|
355
|
+
- Ask on the [[http://groups.google.com/group/jeweler-rb][mailing
|
356
|
+
list]] for feedback on your proposal, to see if somebody else has
|
357
|
+
done it.
|
358
|
+
- Check out the
|
359
|
+
[[http://github.com/technicalpickles/jeweler/issues][issue tracker]]
|
360
|
+
to make sure someone already hasn't requested it and/or contributed
|
361
|
+
it
|
362
|
+
- Fork the project
|
363
|
+
- Start a feature/bugfix branch
|
364
|
+
- Commit and push until you are happy with your contribution
|
365
|
+
- Make sure to add tests for the feature/bugfix. This is important so I
|
366
|
+
don't break it in a future version unintentionally.
|
367
|
+
- Please try not to mess with the Rakefile, version, or history. If you
|
368
|
+
want to have your own version, or is otherwise necessary, that is
|
369
|
+
fine, but please isolate it to its own commit so I can cherry-pick
|
370
|
+
around it.
|
371
|
+
|
372
|
+
** Copyright
|
373
|
+
|
374
|
+
Copyright (c) 2008-2010 Josh Nichols. Copyright (c) 2016 Fred Mitchell.
|
375
|
+
See LICENSE for details.
|