What do you mean by not backwards compatible? From the API perspective it
should be binary compatible, and should be able to run old topologies without a
recompile (assuming no dependencies from storm were used, and I believe at
least one config was removed, but you would have to check). When recompiling a
new NotAuthorizedException can be thrown by some APIs that will need to be
handled. From an end user perspective the big difference is in the
dependencies, especially around shading of dependencies. This means that end
users will want to recompile their topologies using at least 0.10.0, so that
maven packages their dependencies in the uber jar correctly.
The REST API should still be backwards compatible.
- Bobby
On Monday, June 8, 2015 4:19 PM, P. Taylor Goetz <[email protected]> wrote:
I’m working on a blog post for the 0.10.0 release and plan on highlighting the
main new features. There are a lot and I want to make sure I mention them.
Below is what I have off the top of my head (in no particular order aside from
the fist):
* Security (the big one)
* Support for future rolling upgrades
* Kafka integration improvements
* Hive integration
* MS Azure Eventhubs Integration
* Redis integration
* JDBC integration
* Partial key grouping
* Dependency conflict reduction
* Topology deployment and testing tool (flux)
* New logging framework
If you think I missed anything let me know. And if you think of any important
points for any of the above that you’d like to see included, let me know.
I’d also like to include a list of changes that are not backward compatible.
I’m not sure we need it for the announcement, but we should definitely add it
to the documentation. We don’t currently track that information in JIRA (we
should consider doing so), so if anyone can help with compiling a list, I’d
appreciate it.
I will try to send out a draft for review tomorrow.
And most importantly, thanks and congratulations to everyone who contributed to
this release, it’s a big one!
-Taylor
