You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
*[continuous integration](https://scalacenter.github.io/platform-staging/ci-integration.html), and
30
31
* a release manager.
31
-
32
+
32
33
The sbt-platform plugin bundles together many tasks required for Scala Platform
33
34
libraries such as; configuring automatic nightly builds, automatic releases of
34
35
stable versions when a git tag is found, MiMa compatibility checks and PGP
35
36
signatures for artifacts (with Scala Platform keys), integration with our Drone
36
37
setup for writing your own sbt scripts, and other configuration that is
37
-
oftentimes tedious to manage. Continuous integration (CI) is provided by Drone,
38
-
on an EPFL cluster.
39
-
40
-
The CI integration comes with a default Scala template that requires minor
38
+
oftentimes tedious to manage.
39
+
40
+
Continuous integration (CI) is provided by Drone, on an EPFL cluster. The CI
41
+
integration comes with a default Scala template that requires minor
41
42
customization, and yet allows users to remotely configure the build, store their
42
43
tokens, send notifications and act on certain events.
43
-
44
+
44
45
When new changes are forwarded to the corresponding projects' `platform-release`
45
46
branch, our release manager releases them every night. If anything goes wrong,
46
47
it will notify maintainers via email with an error log.
47
48
48
49
## Governance
49
-
50
+
50
51
The Scala Platform process also establishes process and policies to enable
51
52
outside contributors, companies, and industrial users to contribute back to the
52
-
modules, and to help along the modules’ maintenance.
53
-
53
+
modules, and to help along the modules’ maintenance.
54
+
54
55
The goals of these policies are to create and evolve friendly communities around
55
56
the modules and to provide a way for libraries to synchronize on releases and
56
57
updates while still providing stability guarantees to users. For that, the
57
58
process offers contracts for maintaining and contributing to modules as well as
58
-
a [predictable release process](https://scalacenter.github.io/platform-staging/policies.html#policies-on-release-and-stability).
59
-
59
+
a [predictable release process](https://scalacenter.github.io/platform-staging/policies.html#policies-on-release-and-stability).
60
+
60
61
The aforementioned policies can be best summed up as a slightly [modified version
61
62
of the C4 contract](https://scalacenter.github.io/platform-staging/policies.html#policies-on-committers-and-contributors), Pieter Hintjens’ set of rules that made ZeroMQ successful.
62
-
63
+
63
64
### The Collective Code Construction Contract (C4) contract
64
65
65
66
The C4 process can perhaps be most succinctly motivated by its goals, taken directly from [the C4 specification](https://rfc.zeromq.org/spec:42/C4/):
66
-
67
-
> C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:
68
-
> 1. To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;
69
-
> 1. To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;
70
-
> 1. To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;
71
-
> 1. To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;
72
-
> 1. To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;
73
-
> 1. To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.
74
-
67
+
68
+
<blockquote>
69
+
C4 is meant to provide a reusable optimal collaboration model for open source software projects. It has these specific goals:
70
+
<ol>
71
+
<li>To maximize the scale and diversity of the community around a project, by reducing the friction for new Contributors and creating a scaled participation model with strong positive feedbacks;</li>
72
+
<li>To relieve dependencies on key individuals by separating different skill sets so that there is a larger pool of competence in any required domain;</li>
73
+
<li>To allow the project to develop faster and more accurately, by increasing the diversity of the decision making process;</li>
74
+
<li>To support the natural life cycle of project versions from experimental through to stable, by allowing safe experimentation, rapid failure, and isolation of stable code;</li>
75
+
<li>To reduce the internal complexity of project repositories, thus making it easier for Contributors to participate and reducing the scope for error;</li>
76
+
<li>To enforce collective ownership of the project, which increases economic incentive to Contributors and reduces the risk of hijack by hostile entities.</li>
77
+
</ol>
78
+
</blockquote>
79
+
75
80
As an example, the C4 contract sets rules for developer interaction such as what
76
81
happens when someone submits a patch, how users should create pull-requests and
77
82
motivate them, how maintainers can evolve and document APIs, or how they should
78
83
deal with bad actors in case of a conflict.
79
-
84
+
80
85
Our modifications to the process focus on minor Scala Platform requirements and
81
86
licensing, where all modules can choose their open-source licenses so long as
82
87
they are compatible with the modules already in the Platform. For those that
83
88
don't have one yet, Mozilla Public License v2 is recommended. The complete
The predictable release process allows potential contributors to more easily
89
-
reason about releases. It consists of three release pipelines:
94
+
reason about releases. It consists of three release pipelines:
90
95
91
-
* nightly (for beta testers and early adopters),
96
+
* nightly (for beta testers and early adopters),
92
97
* stable (for users), and
93
-
* bug fixes (in case that critical bugs are found).
94
-
98
+
* bug fixes (in case that critical bugs are found).
99
+
95
100
While nightlies are published automatically every night, stable versions of
96
101
platform libraries are released cyclically every 12 weeks, if a release is
97
102
ready.
98
-
103
+
99
104
The release process asks modules to use semantic versioning to reflect breaking
100
105
behaviour. Therefore, major releases happen every 18 months or when new Scala
101
106
versions are released. Maintainers that want to experiment with major changes
102
107
can use the @experimental annotation, whose semantics are documented [here](https://scalacenter.github.io/platform-staging/platform.html#expectations).
103
-
108
+
104
109
Modules also need to be cross-compiled with the latest two Scala major versions
105
110
and, in order to ensure Platform's long-term compatibility, bug fixes are
106
111
accepted and released for major Platform releases in the last 24 months. Those
107
112
modules that fall unmaintained are removed in every major release.
108
-
113
+
109
114
### The current draft
110
115
111
116
We think that the benefits of these policies are twofold: they help maintainers
112
117
and contributors to organize themselves and they make it easier for outside
113
118
contributors, companies and organizations to engage in the development of these
114
119
libraries.
115
-
120
+
116
121
With the help of the Scala Platform Committee members, we have drafted these
117
-
processes in the Scala Platform specification.
118
-
122
+
processes in the Scala Platform specification.
123
+
119
124
These policies are open for discussion and we hope that the Scala community will
120
125
help us improve them!
121
-
126
+
122
127
## The Committee
123
128
124
129
The Scala Platform Committee is exclusively composed of members of the Scala
125
130
community. They set the direction of the Platform, review proposals from the
126
131
community, and decide on the modules that join the Platform.
127
-
132
+
128
133
The members of the Committee are dedicated developers with a long record of
129
134
contributions to the Scala ecosystem, the development of the language and major
130
135
open-source projects. They have been elected to represent and serve the broad
131
136
interest of the Scala community, not their personal or employers' viewpoints.
132
-
137
+
133
138
1. Dale Wijnand (@dwijnand)
134
139
1. Aleksandar Prokopec (@axel22)
135
140
1. Lars Hupel (@larsrh)
@@ -147,11 +152,11 @@ To make the Scala Platform successful, we need the help from the Community. Here
147
152
1. Make suggestions to improve the Scala Platform policies on our [Scala Contributors Discourse Forum][discourse].
148
153
1. Create a Scala Platform proposal;
149
154
1. Discuss and give feedback on current proposals on our [Scala Contributors Discourse Forum][discourse];
150
-
155
+
151
156
The process has been designed to “give feedback early, give feedback often” on
152
157
any proposal. We encourage you to [get your hands dirty and submit
0 commit comments