Thanks, Justin Indeed, own Artemis releases will always be an option, but there are few drawbacks I can see with this approach: - It will be an unofficial release and clients who receive software with this unofficial library will be naturally cautious about it; - Since it will be a private release it will require an additional effort for publishing it to MavenCentral or the like.
If a branch off 2.19.0 will be created in the official repo, I am more than willing to participate in the cherry-picking exercise to backport the fix that I require with a hope that it will eventually be officially released as part of 2.19.x. Thanks, Viktor -----Original Message----- From: Justin Bertram <[email protected]> Sent: 22 December 2021 17:18 To: [email protected] Subject: Re: [DISCUSS] JDK 1.8 support for ActiveMQ Artemis In my opinion only the most critical fixes involving security or stability should be back-ported. That said, I think we'd need more than just a single user here to warrant the effort to back-port and perform releases. Of course, in an ideal world the folks who actually need the fixes & releases would share the work-load. That would make this whole endeavor more viable. Lastly, it's worth mentioning that anybody can maintain their own branch and perform their own releases using 2.19.0 as a base. If the demand isn't high enough to warrant general releases I expect this is what we'd recommend. Justin On Wed, Dec 22, 2021 at 11:04 AM Clebert Suconic <[email protected]> wrote: > I wonder what should qualify for the cherry picking. > > One thing I must ask. To always use cherry pick -x > > I have a report tooling that would help to XREF the branches. > > On Wed, Dec 22, 2021 at 10:00 AM Viktor Kolomeyko > <[email protected]> wrote: > > > Hello, > > I would like to cast my vote supporting 2.19.x branch for JDK 1.8 users. > > We do have a version of our product which is still running on JRE > > 1.8 and we do need some critical fixes to be applied. > > In particular, I would want to see > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fis > > sues.apache.org%2Fjira%2Fbrowse%2FARTEMIS-3593&data=04%7C01%7C%7 > > C20e3cc37cf6848894ce008d9c56f1df5%7Ca4be1f2e2d10419587cd736aca9b672c > > %7C0%7C1%7C637757903315620163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj > > AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdat > > a=2dlPzdS3zAoKPDcWqPZ0I2rp5Vv92MzAT6aXn3yWhqQ%3D&reserved=0 to > > be included into > > 2.19.1 > > Many thanks, > > Viktor Kolomeyko > > > > On 2021/12/15 17:27:26 Clebert Suconic wrote: > > > I just sent ActiveMQ Artemis 2.20.0 to be reviewed under Vote. and > > > I would like to clarify that JDK 1.8 will not be supported any > > > more from Artemis 2.20.0 > > > > > > > > > At this point I don't think we need to create a 2.19.x branch for > > > JDK > > > 1.8 Users. > > > > > > I would like to hear from anyone who can't move to JDK 11 here ... > > > > > > Here is a space for your complaints if you can't move, and I > > > space for us to convince you to move out of JDK 8 :) > > > > > > I had a few conversations with many other teams and I don't > > > foresee a reason to.. so, let me know if I'm wrong here. > > > -- > > > Clebert Suconic > > > > > > > R3 is committed to ensuring the security and protection of the > > personal data that we process, and to provide a compliant and > > consistent approach > to > > data protection. Any personal data that is shared as part of any > > email correspondence with R3 shall be processed in line with the R3 > > Privacy > > Policy<https://nam04.safelinks.protection.outlook.com/?url=https%3A% > > 2F%2Fwww.r3.com%2Ffull-privacy-policy%2F&data=04%7C01%7C%7C20e3c > > c37cf6848894ce008d9c56f1df5%7Ca4be1f2e2d10419587cd736aca9b672c%7C0%7 > > C1%7C637757903315620163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi > > LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9jow > > Uaa5HrjVgZZd3x2gPlL%2BwlSfbVkxuHXYbsAz%2F0E%3D&reserved=0> > > > -- > Clebert Suconic > R3 is committed to ensuring the security and protection of the personal data that we process, and to provide a compliant and consistent approach to data protection. Any personal data that is shared as part of any email correspondence with R3 shall be processed in line with the R3 Privacy Policy<https://www.r3.com/full-privacy-policy/>
