In the project I am working, I have to reuse a project which uses storm 0.9.7.
I do not want to upgrade to higher version as it would need a lot of code changes I I am expected to reuse that code.
Is Storm version 0.9.7 still supported? Or is support for 0.9.7 dropped?
If Storm 0.9.7 is not supported, I may have to rewrite the code
As far as I know development on 0.9.x has stopped. You might still be able to get answers to your questions on the user mailing list, but I'd move to a more recent release.
Related
My team has just upgraded from SpringBoot 1.5.12.RELEASE to 2.4.1 but only to discover that a few days after this major upgrade the documentation references for 2.4.1 have suspiciously and unexpectedly vanished from the documentation page at https://spring.io/projects/spring-boot#learn
We cannot afford that frequent upgrades.
The current GA release is 2.4.2
Why did 2.4.1 disappear?
Was there something fundamentally wrong with 2.4.1 that we should be aware of?
Is there a release plan we can follow going forward?
The Spring project pages only list the most recent patch versions.
I believe this answers my question.
At the company where I am working, there is a huge codebase currently running on Ruby 1.6.8 (2002), which I am tasked with updating to the latest possible version.
There already exists a documentation, which explains how to update the code to Ruby 1.9.3, but even then there is not much documentation which explains the changes which 2.x introduced.
This documentation is also not ideal for me, since it wasn't extensive enough. Is there a website where I can find the changelogs for every Ruby version?
Here https://www.ruby-lang.org/en/downloads/releases/ are the changelogs of each version.
I have questions concerning cdh and how it is maintained:
when I go to the packaging info related to a specific cdh version, I can check the package version of each component (for instance for cdh 5.5.5 : https://www.cloudera.com/documentation/enterprise/release-notes/topics/cdh_vd_cdh_package_tarball_55.html#cdh_555 ). However I don't understand what does the "package version" refers to exactly. For instance, for the component Apache Parquet, the "package version" is parquet-1.5.0+cdh5.5.5+181 . How can I find out exactly what source code is packaged ? Does this correspond to a label on a specific repo? If I go to the "official" apache parquet repo, there is no "cdh5.5.5" branch, the closest thing I have is a tag called "1.5.0" ( https://github.com/apache/parquet-mr/tree/parquet-1.5.0 ) . How do the people from cdh know what parquet-1.5.0+cdh5.5.5+181 exactly refers to ?
Still concerning Apache Parquet, how come even the most recent cdh versions are still using the Apache Parquet on tag is 22 May 2014, ie more than 3 years ago. Why don't they upgrade to a newer version, like 1.6.0 ? The reason I'm asking is that there is a bug in 1.5.0 that was fixed more than 3 years ago in parquet 1.6.0, yet the latest cdh version is still using the 1.5.0 version. Is there a reason why they keep using a really old, bugged, version?
thanks !
You are correct in assuming parquet-1.5.0+cdh5.5.5+181 is closest to parquet 1.5.0. However the code will not be identical to parquet 1.5.0
upstream because:
CDH enforces cross component compatibility. Code and applications using parquet-1.5.0 must also work with all the other Hadoop services (HDFS, Hive, Oozie, YARN, Spark, Solr, HBase). Incompatibilities would have to be fixed so parquet's code would include those bug fixes.
CDH enforces major version compatibility. This means an application written on CDH5.1 should still work on CDH5.5 and CDH5.7, all CDH5.x versions. This also would alter the codebase.
The best way to interpret this is to say that parquet-1.5.0+cdh5.5.5+181 will support all features provided in parquet 1.5.0 and will also work with the corresponding Hadoop services packaged with CDH5.5.
Version compatibility is also the reason why CDH Hadoop service versions run older versions of the related upstream projects. It's much harder to maintain backwards compatibility especially if APIs change between versions.
Is DWR a dead project? It does not appear to be under active development. The latest 3.0 release appears to be stalled. I'm specifically wondering if there are going to be maintenance releases of DWR 1.x or 2.x or is 3.0 is ever going to be released.
BTW. I asked this question on one of the DWR mailing lists and did not get a response.
Well, the 3.0 version is taking a while to get released, but it is nonetheless very stable.
We are using it in our production environment and we do did encounter any issue so far (2+ years in use).
Important issues on 2.0.X are fixed BTW. (seems that currently there are no major issues on 2.0.X).
BTW. I asked this question on one of the DWR mailing lists and did not get a response.
We had issues before (other version) and those were handler very quick.
Update Dec/2015: V3.0.1 released
Seems like it, I have used DWR like a year back and there is no release since then.
Their version 3 is still on RC (release candidate) and from my understanding of versioning, it is not stable or a general acceptance.
I would say move on... pass DWR. Pass Java too if you can ;)
I've been trying to build the 3.2.2 and 3.2.3 tags of WSO2 Carbon from here using Maven 2:
https://wso2.org/repos/wso2/tags/carbon/3.2.2
https://wso2.org/repos/wso2/tags/carbon/3.2.3
However, the Maven pom.xml files throughout the directory trees beneath these tags still refer to version 3.2.0 in both cases - am I missing something obvious please?
When I try and analyse the results of both the builds using our in-house tool I get identical results in the two cases (and indeed results that are identical to those for 3.2.0), which makes me think I may be building 3.2.0 repeatedly by accident.
3.2.2 and 3.2.3 are point releases and typically involves bug fixes/optimizations that do not introduce new features to the 3.2.0 release. If a particular component do not have any fixes/changes, the version still be the older version, no new version is introduced. This is how the versions are handled.
You're not missing anything. It seems they did screw up. Maybe that was their intention, but then it doesn't make any sense at all (at least for me).