[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-dev
Subject:    Re: [PROPOSAL] Regular releases pace and clean schedule on the website
From:       Christopher Shannon <christopher.l.shannon () gmail ! com>
Date:       2021-02-01 16:14:18
Message-ID: CACHnxzyTyMQNTmuAbtdL56CCSXSwvLUGsCO1fVr6YULHQkM0zA () mail ! gmail ! com
[Download RAW message or body]


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 <mattrpav@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 <jb@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.shannon@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.gemmell@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 <jb@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
> >>>
> >
>
>


[prev in list] [next in list] [prev in thread] [next in thread]