Add “library author guide” page #1273
Conversation
julienrf
force-pushed
the
developer-guide
branch
from
e5aa3b2
to
9b50b84
Compare
|
|
||
| The tut tool will produce the following Markdown file: | ||
|
|
||
| {% highlight markdown %} |
There was a problem hiding this comment.
The CI fails because my Markdown file contains a Markdown snippet that contains a tut snippet. I’m not sure how I can write my Markdown snippet in such a way that tut ignores its content.
_overviews/contributors/index.md
Outdated
|
|
||
| Once you have chosen a license, *apply* it to your project by creating a `LICENSE` file in the root directory | ||
| of your project with the license contents or a link to it. This file usually indicates who owns the copyright. | ||
| We suggest putting the project “contributors” as copyright owners. You can see our |
There was a problem hiding this comment.
Not sure about this sentence ("We suggest..."), it doesn't seem clear to me. Also not sure what the scare quotes are for around "contributors". Possibly just omit this sentence, if making it clearer would take up too much space?
There was a problem hiding this comment.
Updated as follows:
-We suggest putting the project “contributors” as copyright owners. You can see our
-[LICENSE file](https://github.com/scalacenter/library-example/blob/master/LICENSE) as an example.
+In our example of [LICENSE file](https://github.com/scalacenter/library-example/blob/master/LICENSE), we have
+written that all the contributors (as per the Git log) own the copyright.
julienrf
force-pushed
the
developer-guide
branch
from
9b50b84
to
f5390a6
Compare
julienrf
force-pushed
the
developer-guide
branch
from
6f22305
to
8295511
Compare
|
I’ve pushed a hacky workaround to not make the CI fail in 8295511. There is still a failure, though, but unrelated to this PR. |
|
this hasn't showed up at https://docs.scala-lang.org/overviews/index.html , presumably for the same reason #1088 didn't show up either /cc @jvican |
|
it's there now, as per |
I wanted to gather in one place the typical things developers want to set up when they start publishing a library. How to publish jars to Maven Central? How to set up a documentation website? How to set up a CI server? How to detect binary incompatibilities between minor versions? How to make all of these tasks painless and as automated as possible?
The resulting document is quite long, although I’ve tried to list as few options as possible. For instance, I only show how to generate documentation with paradox, but there are plenty of alternatives (e.g., microsites is a popular one). The idea was to be able to have a simple set up that can be used a starting point and adapted to more specific needs.
In the end, I’m quite happy with the build.sbt and .travis.yml I have, which are rather simple compared to all they do!
However, I see one serious limitation to what I have: it doesn’t show how to target Scala.js. Supporting this would add a little bit more complexity to the build (ie, we would have to switch to a multi-project build), which I didn’t want to have.