Publish release as 1.1.0

[ashawley]

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

• Increment version to 1.10, not 1.07 Bump version to 1.1.0 #158
• Update Stack deprecation docs Improve wording on stack deprecation #157
• Improvements to top-level docs Improve high-level api docs #165

Release notes

• Add Scala.js support with Fix #49: Add Scala.js support #109, use latest Scala.js #131, Remove test duplication #133
• Fix ISO-8859-1 is used as default encoding #121, changes default encoding in XML.save to UTF-8 in Change default encoding in XML.save to UTF-8 #122
• Fix leafTag is unused in PrettyPrinter.scala #46 with new config for minimizing tags in PrettyPrinter, see Add new config for PrettyPrinter to minimize empty tags #90
• Fix defect XMLEventReader does not handle ' properly #72 XMLEventReader does not handle ' properly with Fix #72 XMLEventReader does not handle ' properly #89
• Fix defect SI-9060: Accept fifth-edition names. #44 with fifth-edition names SI-9060 in Fix #44 SI-9060 XML 5th edition name characters #93
• Fix defect NodeBuffer does print as ArrayBuffer #115 NodeBuffer.toString with Fix #115 NodeBuffer.toString #117
• Fix defect Scaladoc links to Scala standard library not being generated #118 Scaladoc links in apidocs to Scala standard library with Modify SBT to have api mapping to Scala library for scaladoc #119
• Fix performance issue Fix contention due to lzycompute synchronised access in Metadata.normalize #136 lock contention from lazy val in MetaData.normalize
• Revert Utility.escape implementation to use Iterator instead of while with Revert imperative Utility.escape from 81d7e2a #102
• Fixed defect NodeSeq.Empty is not serializable #154 with NodeSeq serialization with Nodeseq serialization #155
• Fixed defect Xml.serialize stripComments parameter doesn't work #183 with stripComments

[godenji]

@ashawley got an ETA for the 1.1.0 release?

[ashawley]

@godenji No, not yet

[ashawley]

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?

[joescii]

@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 NodeSeq to be serializable for some new features being added in 3.2, but Lift will be broken by #150.

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.

[ashawley]

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?

[joescii]

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.

[joescii]

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?

[ashawley]

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.

[joescii]

Give me a few minutes to do some git fu, and I'll push a pair of branches to my fork for some review.

[joescii]

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. master is fine as is if y'all want it to continue as the latest and greatest.

[ashawley]

Thanks @joescii for all your work on this. I grabbed your branch. I'm sure it will come in handy.

[godenji]

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?

[ashawley]

@godenji I hope so!

[SethTisue]

anything I, or anyone else interested, can help with here...?