You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Jean-Baptiste Onofre <jb...@nanthrax.net> on 2021/01/28 16:58:41 UTC
[PROPOSAL] Regular releases pace and clean schedule on the website
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
Re: [PROPOSAL] Regular releases pace and clean schedule on the website
Posted by Christopher Shannon <ch...@gmail.com>.
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 <ma...@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
> >>>
> >
>
>
Re: [PROPOSAL] Regular releases pace and clean schedule on the
website
Posted by Matt Pavlovich <ma...@gmail.com>.
+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 <ch...@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 <ro...@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
>>>
>
Re: [PROPOSAL] Regular releases pace and clean schedule on the
website
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <ch...@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 <ro...@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
>>
Re: [PROPOSAL] Regular releases pace and clean schedule on the website
Posted by Christopher Shannon <ch...@gmail.com>.
+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 <ro...@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
>
Re: [PROPOSAL] Regular releases pace and clean schedule on the website
Posted by Robbie Gemmell <ro...@gmail.com>.
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
Re: [PROPOSAL] Regular releases pace and clean schedule on the
website
Posted by Matt Pavlovich <ma...@gmail.com>.
+1 !!!
> On Jan 28, 2021, at 12:39 PM, JB Onofré <jb...@nanthrax.net> wrote:
>
> Hi Matt
>
> Yes it’s what I was referring by « details » (JDK, JMS version, etc).
>
> +1 !
>
> Regards
> JB
>
>> Le 28 janv. 2021 à 19:30, Matt Pavlovich <ma...@gmail.com> a écrit :
>>
>> Hi JB-
>>
>> I think this is a good idea, esp w/ the JDK and Jakarta movement the way it is.
>>
>> What do you think about adding the JDK, JEE, standards APIs and protocol versions into the table? (like Karaf does, which I think is very useful). Maybe the messaging protos and API versions in a separate tablet to keep the first one about release cadence?
>>
>>
>> 5.17.x — JDK11, Jakarta?, JMS v2.0, MQTTv5?
>> 5.16.x —
>> 5.15.x — JDK 8, JEE, JMS v1.0, MQTTv3
>>
>> Thanks!
>> -Matt
>>
>>> On Jan 28, 2021, at 10:58 AM, 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
>>
>
Re: [PROPOSAL] Regular releases pace and clean schedule on the website
Posted by JB Onofré <jb...@nanthrax.net>.
Hi Matt
Yes it’s what I was referring by « details » (JDK, JMS version, etc).
+1 !
Regards
JB
> Le 28 janv. 2021 à 19:30, Matt Pavlovich <ma...@gmail.com> a écrit :
>
> Hi JB-
>
> I think this is a good idea, esp w/ the JDK and Jakarta movement the way it is.
>
> What do you think about adding the JDK, JEE, standards APIs and protocol versions into the table? (like Karaf does, which I think is very useful). Maybe the messaging protos and API versions in a separate tablet to keep the first one about release cadence?
>
>
> 5.17.x — JDK11, Jakarta?, JMS v2.0, MQTTv5?
> 5.16.x —
> 5.15.x — JDK 8, JEE, JMS v1.0, MQTTv3
>
> Thanks!
> -Matt
>
>> On Jan 28, 2021, at 10:58 AM, 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
>
Re: [PROPOSAL] Regular releases pace and clean schedule on the
website
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
Hi Etienne,
Thanks for your feedback.
Yeah, we can avoid to specify "Not Active" as we can always cut a release "on demand". The purpose was to be very clear for users, but release date would be enough.
Regards
JB
> Le 28 janv. 2021 à 19:51, Hossack, Etienne <eh...@amazon.com.INVALID> a écrit :
>
> Hi all,
> Adding my voice in here if you don’t mind!
> This sounds like a good path forward for ActiveMQ users - having a clear status wording would certainly be valuable for recommending upgrades.
>
> Do you think it is worth being specific about how a branch becomes “Not Active”.
> For example, “only branches newly released in the last 12 months” or “latest 2 non-development versions”?
>
> +1 for adding JDK/JRE requirements - would be very helpful during evaluation and environment setup also.
>
> Cheers!
> Étienne
>
> Étienne Hossack
> Software Development Engineer, Amazon MQ
> email: ehossack@amazon.com <ma...@amazon.com>
> phone: +1-778-945-8287
>
>
>
>> On Jan 28, 2021, at 10:30 AM, Matt Pavlovich <mattrpav@gmail.com <ma...@gmail.com>> wrote:
>>
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>
>>
>>
>> Hi JB-
>>
>> I think this is a good idea, esp w/ the JDK and Jakarta movement the way it is.
>>
>> What do you think about adding the JDK, JEE, standards APIs and protocol versions into the table? (like Karaf does, which I think is very useful). Maybe the messaging protos and API versions in a separate tablet to keep the first one about release cadence?
>>
>>
>> 5.17.x — JDK11, Jakarta?, JMS v2.0, MQTTv5?
>> 5.16.x —
>> 5.15.x — JDK 8, JEE, JMS v1.0, MQTTv3
>>
>> Thanks!
>> -Matt
>>
>>> On Jan 28, 2021, at 10:58 AM, Jean-Baptiste Onofre <jb@nanthrax.net <ma...@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> <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/> <http://activemq.apache.org/components/classic/download/ <http://activemq.apache.org/components/classic/download/>>
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>
>
Re: [PROPOSAL] Regular releases pace and clean schedule on the website
Posted by "Hossack, Etienne" <eh...@amazon.com.INVALID>.
Hi all,Adding my voice in here if you don’t mind!
This sounds like a good path forward for ActiveMQ users - having a clear status wording would certainly be valuable for recommending upgrades.
Do you think it is worth being specific about how a branch becomes “Not Active”.
For example, “only branches newly released in the last 12 months” or “latest 2 non-development versions”?
+1 for adding JDK/JRE requirements - would be very helpful during evaluation and environment setup also.
Cheers!
Étienne
Étienne Hossack
Software Development Engineer, Amazon MQ
email: ehossack@amazon.com<ma...@amazon.com>
phone: +1-778-945-8287
[cid:0CFB4B72-BC66-42A8-953C-779D7FAE3DC0@amazon.com]
On Jan 28, 2021, at 10:30 AM, Matt Pavlovich <ma...@gmail.com>> wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
Hi JB-
I think this is a good idea, esp w/ the JDK and Jakarta movement the way it is.
What do you think about adding the JDK, JEE, standards APIs and protocol versions into the table? (like Karaf does, which I think is very useful). Maybe the messaging protos and API versions in a separate tablet to keep the first one about release cadence?
5.17.x — JDK11, Jakarta?, JMS v2.0, MQTTv5?
5.16.x —
5.15.x — JDK 8, JEE, JMS v1.0, MQTTv3
Thanks!
-Matt
On Jan 28, 2021, at 10:58 AM, 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
Re: [PROPOSAL] Regular releases pace and clean schedule on the
website
Posted by Matt Pavlovich <ma...@gmail.com>.
Hi JB-
I think this is a good idea, esp w/ the JDK and Jakarta movement the way it is.
What do you think about adding the JDK, JEE, standards APIs and protocol versions into the table? (like Karaf does, which I think is very useful). Maybe the messaging protos and API versions in a separate tablet to keep the first one about release cadence?
5.17.x — JDK11, Jakarta?, JMS v2.0, MQTTv5?
5.16.x —
5.15.x — JDK 8, JEE, JMS v1.0, MQTTv3
Thanks!
-Matt
> On Jan 28, 2021, at 10:58 AM, 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