+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 >