I think Clebert covered the fact that no one's going to give you an official statement of guaranteed support; if you want that, contact one of the vendors who offer that and get a quote. But since we're an open-source project with a publicly visible issue tracking system, if there's an issue you really want fixed in your version that's only been fixed in a later one, you're always able to patch it yourself and recompile your custom patch version and use that. And if you're having trouble working out some incompatibility between the patch and the version you want to apply it to, you'll get some help from the dev mailing list (or the users mailing list, though I think your odds are better on dev).
But be forewarned that troubleshooting bugs in 6-year-old versions isn't something most people are going to spend their time on, so you shouldn't plan to lock into a version and then never upgrade it and expect a lot of support from the community. You should probably be running versions that are no more than ~2-3 years old, and should plan to upgrade periodically to stay in that rough window, otherwise you may get less (free) support from the community and you might want to rely on paid support from vendors. What Chris said about backwards compatibility of OpenWire is correct, but the best way to describe the approach to compatibility overall is that we attempt to make all versions backwards compatible, but as far as I know there isn't any formal effort to test that compatibility so we don't claim that it will work, just that we think it should. And in the year and a half of monitoring this list, I don't believe I've seen any posts indicating any backwards incompatibilities in client-to-broker connections. So your mileage may vary, but there are few to no reports of poor mileage. Note, however, that there are sometimes incompatibilities when upgrading the broker itself, such as the fact that the persistent message store reads and writes only one version of OpenWire so the broker may be unable to read messages from the persistent store if the OpenWire version was different between the two versions. Tim On Sat, Jan 30, 2016 at 12:32 PM, Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > There isn't really any official amount of time that a release is support as > releases are community driven. If there is someone who requests a release > or bug fix version and others agree, then it will happen. There is usually > a bug fix release or 2 per version, but not always. For example, I am > planning to do a 5.13.1 release soon but whether or not a 5.13.2 is done > will depend on if there are enough fixes to warrant it or if someone > requests it. > > For backwards compatibility, what do you mean by does 5.4 work with 5.13? > Do you mean does a 5.4 client work with a 5.13 broker? The java client > uses OpenWire which is a protocol that allows for version negotiation, so > the broker and client will negotiate the OpenWire version and will work. > However, features in new versions of OpenWire wouldn't be available. The > same thing would go with 2 brokers networked as they would use OpenWire to > communicate. That being said, you are always better off to match clients > and servers with the same version because all of the testing that is done > is against matching versions. (the unit tests always test a 5.13.0 client > against a 5.13.0 broker, for example) > > On Sat, Jan 30, 2016 at 11:59 AM, Clebert Suconic < > clebert.suco...@gmail.com > > wrote: > > > I am not a lawyer, but if you look at the apache license > > (http://www.apache.org/licenses/LICENSE-2.0): > > > > "7. Disclaimer of Warranty. Unless required by applicable law or > > agreed to in writing, Licensor provides the Work (and each Contributor > > provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR > > CONDITIONS OF ANY KIND, either express or implied, including, without > > limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, > > MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely > > responsible for determining the appropriateness of using or > > redistributing the Work and assume any risks associated with Your > > exercise of permissions under this License." > > > > > > However there are several vendors offering support and consulting > > around ActiveMQ (including ActivMQ 5 and Artemis): > > > > We all help users through the user's list, but the way you worded your > > email it's implying commercial support, and you should probably > > contact and and request official statements from one of these vendors. > > If you have difficult contacting any, feel free to ping us here so > > someone could then give you an updated contact. but here's a list: > > > > http://activemq.apache.org/support.html > > > > > > > > > > > > On Sat, Jan 30, 2016 at 7:32 AM, wagonmaster <nikola.v...@sas.com> > wrote: > > > I would like to request an official statement from the activemq > > developers on > > > what is the support policy for active mq versions, especially with > > respect > > > to providing security fixes and also backwards compatibility. > > > > > > > > > 1. How many major versions of ActiveMQ are supported? (E.G. Currently > > > 5.11.x, 5.12.x and 5.13.x) > > > > > > 2. How long is each version of ActiveMQ supported (1 year, 2 year, > etc?) > > > > > > 3. What is the expectation for backwards and forwards compatibility > > between > > > different versions of AciveMQ? Does activemq 5.4 work with activemq > 5.13? > > > > > > > > > > > > -- > > > View this message in context: > > > http://activemq.2283324.n4.nabble.com/ActiveMQ-Security-Support-Policy-tp4706678.html > > > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > > > > > > > -- > > Clebert Suconic > > >
