3 months sounds good to me. That's a pretty standard cadence for many projects and should be doable.
On Fri, Jan 29, 2021 at 12:01 PM Matt Pavlovich <mattr...@gmail.com> wrote: > +1 on 3 mos > +1 on focusing JDK8 efforts into the 5.16.x release line > > > On Jan 29, 2021, at 7:47 AM, Jean-Baptiste Onofre <j...@nanthrax.net> > wrote: > > > > 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 > >>> > > > >
