Publish release as 1.1.0 #156
Comments
|
@ashawley got an ETA for the 1.1.0 release? |
|
@godenji No, not yet |
|
I wonder if we should jam in #155 at the last minute and add it to the release, since next release is a major version update? Any comments? |
|
@ashawley I would greatly like to see a 1.0.7 release which includes #155, but doesn't include the breaking change in #150. I'll gladly do the git branch voodoo and submit PRs. The reason is Lift needs Normally the obvious thing to do is release 1.1.0 with #155 (or 1.1.1 if we need to be more conservative with this project), and have Lift 3.2 explicitly depend on 1.1.x. Unfortunately sbt has a bug where it will NOT use the scala-xml version specified the the project classpath, but whatever one the scala compiler wants. What this means is that anyone using Lift 3.2 with 1.1.x will have a broken development environment. The Lift 3.2 binary will expect 1.1.x, but sbt will only use 1.0.x which that particular scala compiler version required. Hence Lift will never successfully run in sbt for development. AFAIK, no one is working on the sbt bug nor is anyone actively looking to address the issue. Given that classpath issues are pretty gnarly and I'm unfamiliar with the sbt code base, I'll be pretty challenged to correct the issue with an acceptable PR. But 1.0.7 with the serialization fix without #150 won't have this problem. Only a small subset of Lift users will enable the feature. Secondly, the feature is for production, not development, hence it doesn't need to behave correctly in sbt. Furthermore, this Lift feature I'm referencing will certainly require some thorough documentation, which can include a caveat about the sbt classpath in case someone tries to use the feature within sbt itself. |
|
Thanks for these comments @joescii I made multiple attempts at the compiler/scaladoc dependency issue for scala-xml. My last one was scala/scala#5689. Being "pretty challenged to correct the issue with an acceptable PR" was my personal flaw as well. I'm happy to entertain your proposals. It sounds like we're pretty hamstrung in making binary changes to the library, IIUC: If we making breaking changes and still use a big version number to signal the breaking change, you're saying the compiler won't let the user actually use an incompatible scala-xml dependency in sbt? The compiler rules in sbt, essentially? |
|
The way you rephrased it is correct. So if you're using scalac 2.12.2 and it depends on scala-xml 1.0.5 (I think that's the version anyway), but your project needs scala-xml 1.1.0, your code is going to get the 1.0.5 jar and blow up. The issue I opened against sbt shows it in close detail. |
|
I don't wanna over impose on a project I've not been dedicating my own time to, but I suspect the sbt bug forces scala-xml into maintaining a branch with zero compatibility changes until the bug can be fixed and released. What do you think? |
|
That's been my conclusion as well. Module system in 2.11 was possibly a feature that never existed. I'm sort of the confused police detective played by Chazz Palminteri in Usual Suspects. |
|
Give me a few minutes to do some git fu, and I'll push a pair of branches to my fork for some review. |
|
It turns out I already had such a branch locally: https://github.com/joescii/scala-xml/tree/revert-150 That branch should be a good branch for your backwards-compatible maintenance branch. I wasn't thinking long enough when I thought we needed a second branch. |
|
Thanks @joescii for all your work on this. I grabbed your branch. I'm sure it will come in handy. |
|
Looks like a release has unfortunately been put on hold by the Lift saga. Would be nice to benefit from the new Scala.js support -- think we'll have something ready before end of the year? |
|
@godenji I hope so! |
|
anything I, or anyone else interested, can help with here...? |
|
Whether to include #165 in 1.1.0, and if so, get a review. Otherwise, I think it's whether to give one more look at the artifacts for Scala.js and Java 9 before finally pushing the tag and cutting a release. |
|
#165 is merged. I suggest not worrying about JDK 9, it's not a blocker for release. We can always do 1.1.1 and beyond. |
|
as for Scala.js, you can ask that someone on the Scala team take a quick look before releasing the artifacts that you stage. also, I wouldn't worry about it too much. if we get it wrong again, Scala.js users will tell us and we can do 1.1.1. in general, I think it's okay to be slightly reckless and not worry too much if there turns out to be something wrong with 1.1.0. there's lots of nice changes to get out there, and the way to get community feedback on whether something broke is to get a release out there. |
Scala xml support in the browser alone is release worthy, nevermind the myriad other fixes/enhancements :) |
|
I've pushed the button and tagged v1.1.0. Let's see how this goes! |
|
I've closed the staging repositories (orgscala-lang-1472, orgscala-lang-1473). shall I release them to Maven Central? |
|
Sounds good to me |
|
whoosh! fly, artifacts, fly! (I did check that the Scala.js artifacts are nonempty.) |
|
perhaps the release notes should say something about binary compatibility? |
|
Agree, it seems worth mentioning.
Any suggestions? |
|
Thanks, Seth. I'm seeing them. I've updated the release notes about binary compatability. |
After hearing from Joe Barnes that #150 was indeed a breaking change for users, we should make the next release 1.1.0 and not 1.0.7. Previous discussion on 1.0.7 is #152
Release notes
XML.saveto UTF-8 in Change default encoding in XML.save to UTF-8 #122PrettyPrinter, see Add new config for PrettyPrinter to minimize empty tags #90XMLEventReaderdoes not handle'properly with Fix #72 XMLEventReader does not handle ' properly #89NodeBuffer.toStringwith Fix #115 NodeBuffer.toString #117lazy valinMetaData.normalizeUtility.escapeimplementation to useIteratorinstead ofwhilewith Revert imperative Utility.escape from 81d7e2a #102NodeSeqserialization with Nodeseq serialization #155stripCommentsThe text was updated successfully, but these errors were encountered: