Closed msgilligan closed 6 years ago
I'm good releasing now and bumping to version 1.5.6 - #70 would be nice to implement now, but I don't think it's a blocker. We also have a bunch of questions in the issues that have gone unanswered that we should take a crack at - seem like easy ones to answer and close out.
How about I walk you through the release process and we can document the process (https://github.com/asciidoctor/asciidoclet/pull/82) at the same time add some redundancy to being able to push releases?
Is #70 just a change the the Maven POM? I don't really understand the issues involved with that change and don't feel it's something I have much expertise to add. I also think it would add some risk. The other changes are relatively low-risk (except perhaps on Java 9, but we previously weren't even working there -- so there's nothing to lose.)
My preference would be to release 1.5.6 and then try making a snapshot release with whatever changes are needed for #70.
I also think that the changes for #70 are probably worthy of at least a minor version bump (e.g. 1.6.0)
Yes, #70 should just be a reconfiguration of the pom... maybe we could also move over to using the shade plugin for the uber-jar.
Changing to 1.6.0 would take us out of lockstep with the reset of asciidoctor, I think we can accomplish this between the releases unless there is a good reason to break with this convention.
Changing to 1.6.0 would take us out of lockstep with the rest of asciidoctor
I was thinking that if we de-bundle asciidoctor (#70), we could decouple the versions, but I guess there might still be a default version.
OK, so I think we should get it working with AsciidoctorJ 1.5.7 and release version 1.5.7.
I also think we should ship unbundled only, unless there is a use case I'm unaware of.
We've decided that only the libraries that provide Asciidoctor need to stay in version alignment (Asciidoctor, AsciidoctorJ, and Asciidoctor.js). The other libraries are free to version independently.
There will also be no release of Asciidoctor 1.6.0. Instead, we're moving to 2.0.0 so we can start following semver. So 1.6.0 is free to use....though you may want to think about jumping to 2.0.0 once core does and then just following semver from that point forward.
Sounds good. I vote for the unbundled distribution to be version 1.6.0 and the Java 9 doclet version of Asciidoclet to be version 2.0.0 then! (not to be in lockstep w/ Asciidoctor)
Well, (as I understand it) the unbundled distribution will still have a transitive dependency on AsciidoctorJ -- currently version 1.5.7. So, that's why I'm proposing version 1.5.7 for the next release.
The Asciidoctor Gradle plugin actually makes it's Asciidoctor dependency configurable in the DSL, but I think using standard (and therefore overridable) POM dependencies for the Doclet is an acceptable solution.
@johncarl81 Should we publish a 1.5.6-SNAPSHOT for testing? Then if all looks well we can move towards a 1.5.6 release.
Sure, just pushed 1.5.6-SNAPSHOT. This version works well across my projects. Let me know how your's fare @msgilligan and we'll look at a release.
I don't see a 1.5.6-SNAPSHOT: https://oss.sonatype.org/content/repositories/snapshots/org/asciidoctor/asciidoclet/
A new 1.5.5-SNAPSHOT appeared however and it seems to magically fix Issue #45 in my ConsensusJ build... @mojavelinux did you make a new SNAPSHOT release of 1.5.5?
Ok, the latest should be up now. By the way, you can alway publish to your local maven repo by running mvn clean install
. I believe this is referenced by mavenLocal()
repository setting in gradle.
I was also responsible for the 1.5.5-SNAPSHOT that I was tinkering around with removing the haml templates.
That experimental 1.5.5-SNAPSHOT seemed to work pretty well for me!
I've also upgraded the Gradle plugin and other tools to the latest versions: https://github.com/ConsensusJ/consensusj/commit/65f2ea68f3a649cfd71a8008830dfb7049b275ae
Trying 1.5.6-SNAPSHOT now...
I have to be wary of the transitive dependencies, they can be displayed with
$ ./gradlew consensusj-jsonrpc:dependencies
asciidoclet
+--- org.asciidoctor:asciidoclet:1.5.6-SNAPSHOT
| +--- org.asciidoctor:asciidoctorj:1.5.6
| | +--- org.jruby:jruby-complete:1.7.26
| | \--- com.beust:jcommander:1.35
| +--- org.slf4j:slf4j-simple:1.7.25
| | \--- org.slf4j:slf4j-api:1.7.25
| \--- com.google.guava:guava:20.0
+--- org.asciidoctor:asciidoctorj:1.5.6 (*)
\--- org.asciidoctor:asciidoctorj-diagram:1.5.8
\--- org.asciidoctor:asciidoctorj:1.5.6 (*)
If I bump asciidoctorj-diagram to 1.5.9 (in my gradle.properties
, it will pull in aciidoctorj 1.5.7 which will break the build.
asciidoclet
+--- org.asciidoctor:asciidoclet:1.5.6-SNAPSHOT
| +--- org.asciidoctor:asciidoctorj:1.5.6 -> 1.5.7
| | +--- org.jruby:jruby-complete:9.1.16.0
| | \--- com.beust:jcommander:1.35
| +--- org.slf4j:slf4j-simple:1.7.25
| | \--- org.slf4j:slf4j-api:1.7.25
| \--- com.google.guava:guava:20.0
+--- org.asciidoctor:asciidoctorj:1.5.6 -> 1.5.7 (*)
\--- org.asciidoctor:asciidoctorj-diagram:1.5.9
\--- org.asciidoctor:asciidoctorj:1.5.7 (*)
OK, so to bump to asciidoclet-1.5.6-SNAPSHOT I have to go back to asciidoctorj 1.5.6 and asciidoctorj-diagram 1.5.8 in my gradle.properties
variable settings:
https://github.com/ConsensusJ/consensusj/commit/2120bbdd67c79951a4d8a980c4fbc6c3a3617d9d
@msgilligan this seems appropriate to me... go for 1.5.6 release?
Yes, let's do it!
We should probably go ahead and release the current version. Maybe we want to bump the version to 1.5.6 so it matches the version of Asciidoctor it uses (until we have a solution for Issue #70)
(We also have to think about Asciidoclet v2.0 which will require Java 9 or later -- so maybe we'll need to start decoupling Asciidoclet versions from Asciidoctor versions)
Changes since 1.5.4:
@johncarl81 @mojavelinux -- what do we need to do before releasing this?