My bad: I did a mistake, the proposal is every 2 months. But you are right, 3 months for both is more "acceptable" and easy.
So basically, a release per quarter is probably do-able. I will try to sustain this schedule. As soon as we have a consensus, I will update the website with the schedule/details. Regards JB > Le 29 janv. 2021 à 13:38, Christopher Shannon > <christopher.l.shan...@gmail.com> a écrit : > > +1000 to everything Robbie said. Robbie pretty nailed down what I wanted to > say. > > The only thing I'll re-iterate is I think a schedule is a good idea but the > main issue I see here is the frequency/pace proposed which seems too > aggressive. Especially the part about "every 2 weeks" which is never going > to happen and is not sustainable based on history. Honestly I think that > promising anything more than a release every 3 months seems iffy to me. > Even monthly probably won't be doable and would often be late. > > Also keep in mind a release means performing the entire process from doing > the release, voting, announcements, website updates, etc so there's a good > amount of work that needs to be done for each release. So we need to be > more realistic on what is and isn't going to happen considering this is all > volunteer work. No one is going to complain if we produce more releases > than promised but under delivering and being late consistently is a really > bad idea after setting user expectations. > > In terms of my own involvement, I am happy to help with releases but only > on occasion and it would be hard to promise when I can do them. I've been > busy the past year or 2 with doing many other things at work now besides > AMQ related things as my tasking has changed a bit so my time to help is > more limited. (been working with Kafka more for one thing) I will still > have some time coming up to support 5.x and help with Artemis but it's just > not as much as it used to be a couple years ago when that was mostly my > full time job. > > On Fri, Jan 29, 2021 at 7:11 AM Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > >> Doing more frequent releases sounds good, and to more of a schedule >> also. Saying what JDK etc a release uses/supports on the site is also >> good. We aren't allowed to direct everyday users to unreleased >> software as a matter of policy, so I would say that 5.17.x shouldnt be >> mentioned until released though. >> >> On the releases, one issue I see with the proposal would be the >> frequency. Are folks actually able to handle a two week cadance, as >> recent years/releases don't really seem to support that? It took 6 >> months to do 5.16.1. It is already heading for 2 weeks since the >> 5.16.1 vote closed and despite apparently containing an announced >> security fix the release still isn't even on the website yet (aside, I >> see the download page is also currently broken once more, as the >> release was again prematurely deleted from the mirrors). This gap >> seems a repeating issue, plus half of the recent releases are also >> never announced, sometimes even after a nudge. Advertising >> expectations of a release every 2 weeks doesn't currently seem >> remotely sustainable. >> >> I would propose a more balanced target being mentioned than that, of >> say at least a month but probably a good bit more. Its always possible >> to over-deliver occasionally if needed/possible. I'd also suggest the >> website only mention proposed frequencies rather than specific dates, >> avoiding needing them to be updated as frequently and often looking >> stale once it inevitably isn't at some point (e.g the given Karaf >> website example, with all of the ETAs mentioned on it having been >> passed by some amount of up to a year). Now that I think about it, I >> also expect there are various points 2 weeks will have passed without >> any changes being made. >> >> Ah. I've only now noticed that the mail said 5.16.x every two weeks, >> but then further qualified it with the end of Feb. I'm assuming the >> 'two weeks' bit is the accurate bit, but perhaps it's not...I've just >> left what I already typed above as-is, I guess the points are mostly >> relevant either way. >> >> I would personally probably be considering retiring 5.15.x at this >> point, or at least deciding when it's likely to be, rather than aiming >> and advertising to do more releases of it. Doesn't it have mostly the >> same JDK support as 5.16.x, and I think a lot of the changes in 5.15.x >> were backported from master/5.16.x before its release and continue to >> be? How different are they actually, i.e what are the main things >> needing both be maintained at this point? Presumably it will drop away >> at some point before 5.16.x does, requiring people to then upgrade to >> e.g 5.16.x+ for fixes etc anyway. Perhaps specifically-so to 5.16.x if >> they are still using JDK8 then. After 15 releases across over 3.5 >> years from 5.15.x (~3 months avg?), and this proposal of more frequent >> 5.16.x releases, now seems the appropriate point for considering this. >> Retiring it would allow concentrating available efforts only on 5.16.x >> and also getting 5.17.x(+) releases out. The former could become the >> 'last JDK 8+ supporting release', eventually being 'in maintenance', >> and the latter could become e.g. the 'JDK 11+ based mainstream >> release'. JDK 17 is also approaching with EA builds already available, >> so maintaining two seemingly similar but separate JDK8+ streams going >> forward feels increasingly odd. Trying to consolidate limited >> resources now on a single JDK8-using release series, that could then >> be maintained for some period, seems to me like it would be better for >> both the project and [JDK8] users in the longer term. >> >> >> On Thu, 28 Jan 2021 at 16:58, Jean-Baptiste Onofre <j...@nanthrax.net> >> wrote: >>> >>> Hi guys, >>> >>> I would like to propose something similar to what we do on Apache Karaf >> regarding releases. >>> >>> http://karaf.apache.org/download.html < >> http://karaf.apache.org/download.html> >>> >>> Basically, my proposal is: >>> >>> - flag any branch < 5.15.x (5.14.x, 5.13.x, …) as "Not Active" >>> - flag 5.15.x and 5.16.x as "Stable" >>> - flag 5.17.x as "Development" >>> >>> About the release cycle, I would like to propose: >>> >>> - 5.15.x release every quarter (meaning that 5.15.15 will be scheduled >> for March, 9th) >>> - 5.16.x release every two weeks (meaning that 5.16.2 will be scheduled >> for end of Feb) >>> >>> I would like to add details about releases schedule (and JDK version >> supported, etc) on >>> >>> http://activemq.apache.org/components/classic/download/ < >> http://activemq.apache.org/components/classic/download/> >>> >>> Thoughts ? >>> >>> Regards >>> JB >>
