@@ -119,6 +119,7 @@ new Frame {
119
119
The reason to have different major versions is to allow for binary incompatible changes. Also, some java-swing classes were
120
120
generified in JDK 7 (see [ SI-3634] ( https://issues.scala-lang.org/browse/SI-3634 ) ) and require the scala-swing sources to be adjusted.
121
121
122
+ Versions now follow classic Scala PVP style with binary compatibility within ` x.y.* ` but not ` x.*.* ` .
122
123
123
124
## API documentation (Scaladoc)
124
125
@@ -130,3 +131,20 @@ at [http://www.scala-lang.org/documentation/api.html](http://www.scala-lang.org/
130
131
131
132
Current changes are being made on the ` work ` branch.
132
133
Last published version is found on the ` main ` branch.
134
+
135
+ ## Publishing New Versions
136
+
137
+ We assume that you are working on a fork of remote ` upstream ` with remote ` origin ` .
138
+
139
+ - create a new local branch that will never be pushed remotely, e.g. ` git checkout -b release-3.0.0#3.0.0-RC2 `
140
+ (do not name the branch the same as a tag)
141
+ - edit ` .travis.yml ` to reduce the matrix to only the Scala and JDK versions needed to publish the version
142
+ (publishing JDK is 8)
143
+ - ` git commit `
144
+ - add a tag, e.g. ` git tag -a 'v3.0.0#3.0.0-RC2' -m 'version 3.0.0 for 3.0.0-RC2' `
145
+ - push __ only the tag__ , e.g. ` git push upstream v3.0.0#3.0.0-RC2 ` .
146
+ - check CI status at [ https://travis-ci.com/github/scala/scala-swing ] ( https://travis-ci.com/github/scala/scala-swing ) .
147
+ You should see a message ` Running ci-release. ` followed by e.g ` published scala-swing_3.0.0-RC2 to ... ` going into
148
+ local ` sonatype-staging ` , followed by the Sonatype plugin uploading the artifacts.
149
+ - Upon success, nudge Seth to release the bundle from Sonatype.
150
+
0 commit comments