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

Reply via email to