Upcoming releases

[Tim Bain <tb...@alumni.duke.edu>]

Would it be worth the effort to create and then maintain a page that lists
the planned timeline of upcoming releases for both 5.x and Artemis? There
have been a lot of questions about upcoming plans in the wake of the Log4J
CVE, but even during normal times we get occasional questions here about
upcoming plans, and that's just the users who bother to sign up for the
mailing list so there could well be more who look for that info but don't
post to ask.

The downside is that once we create a page for that content we'll have to
be diligent about updating it (including publishing updates when something
slides back a bit), otherwise what's the point. I'm not sure if the folks
who would have to do the ongoing work on this think it's worth the effort,
but I wanted to throw it out for consideration.

Tim

Re: Upcoming releases

[Justin Bertram <jb...@apache.org>]

My concern isn't so much with updating the website upon a release. As you
note, we already do that.

My concern is with the other updates that will inevitably be needed when
the schedule slips for whatever reason. If we just stick to a general
release cadence none of that will be necessary.

Regarding release details, we can leverage the "Releases" page [1] [2]
already present in Jira. Folks can click on any release and see what was or
will be in it. It won't be as user friendly as a curated list, but it also
requires zero effort which is a big win in my opinion.


Justin

[1]
https://issues.apache.org/jira/projects/AMQ?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page
[2]
https://issues.apache.org/jira/projects/ARTEMIS?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page

On Tue, Feb 1, 2022 at 12:12 PM Jean-Baptiste Onofre <jb...@nanthrax.net>
wrote:

> Hi Justin,
>
> I think it’s not a huge effort compare to what we already do at each
> release (updating the website).
>
> For instance, for Karaf, it’s pretty quick to update website and release
> schedule at each release cycle.
>
> I already proposed regular release cycle in the past (as best effort).
>
> I would agree with both: regular release cycle (quarterly) + some details
> (at least for “major” releases) on website.
>
> Regards
> JB
>
> > Le 1 févr. 2022 à 18:32, Justin Bertram <jb...@apache.org> a écrit :
> >
> > Generally speaking, I'm against anything that will require more
> maintenance
> > of the website. History indicates that the community is somewhat weak in
> > this area.
> >
> > Correct me if I'm wrong, but from what I can tell we've never
> consistently
> > scheduled releases. Also, given the Apache Way with the release voting
> > process we can only be precise about when a release will go up for a
> vote.
> > There's no way to actually guarantee a release date. Why not have
> > consistent, time-boxed (e.g. quarterly) releases? That would solve a
> > handful of problems:
> >
> > - users could depend on a general cadence for releases
> > - the website could simply outline the release cadence which would
> > alleviate the need for maintenance
> > - it would reduce the communication necessary to coordinate a release; a
> > release manager could simply step up and perform the release when the
> time
> > comes
> >
> > Obviously we can still have "ad hoc" releases as necessary (e.g. due to a
> > security issue).
> >
> > Thoughts?
> >
> >
> > Justin
> >
> > On Tue, Feb 1, 2022 at 6:47 AM Tim Bain <tb...@alumni.duke.edu> wrote:
> >
> >> Would it be worth the effort to create and then maintain a page that
> lists
> >> the planned timeline of upcoming releases for both 5.x and Artemis?
> There
> >> have been a lot of questions about upcoming plans in the wake of the
> Log4J
> >> CVE, but even during normal times we get occasional questions here about
> >> upcoming plans, and that's just the users who bother to sign up for the
> >> mailing list so there could well be more who look for that info but
> don't
> >> post to ask.
> >>
> >> The downside is that once we create a page for that content we'll have
> to
> >> be diligent about updating it (including publishing updates when
> something
> >> slides back a bit), otherwise what's the point. I'm not sure if the
> folks
> >> who would have to do the ongoing work on this think it's worth the
> effort,
> >> but I wanted to throw it out for consideration.
> >>
> >> Tim
> >>
>
>

Re: Upcoming releases

[Tim Bain <tb...@alumni.duke.edu>]

The concerns Justin has voiced are the reason I wasn't sure that adding
such a page would be worth the effort. I think it would be OK to follow
JB's proposal and do it despite those concerns (the consequences of failure
are pretty low), particularly if some small group of people would take
responsibility for making the updates.

But I think we should establish some criteria for deciding that we're not
doing a good enough job of keeping the dates updated and should remove the
dates and stop putting them on the web page. For example, "either two
distinct periods of time within 6 months where a date was known or
reasonably suspected to be inaccurate by more than 1 week, or if a date is
ever stale for 1 month (the release date is realized to have slipped on
date X, but by X plus a month we haven't updated the web page)."

I like the observation by Justin that JIRA can provide some of this
information, but I think we'd want it to be easier to get to. So what if JB
makes a page listing all planned upcoming releases (typically the next
incidental release in each minor version we're maintaining, but as we get
close to releasing x.y.z and define x.y.z+1 in JIRA we'd add it so
sometimes there would be two for some minor versions) with a link to JIRA
and an estimated release date for each. Then if we realize that we're not
keeping the dates updated, we can remove them and add text to the page
telling people to go to JIRA to see how close we seem to be but the overall
rhythm of adding upcoming releases when we define them and removing them
when they ship can remain unchanged.

Thoughts?

Tim

On Fri, Feb 4, 2022, 5:47 AM Robbie Gemmell <ro...@gmail.com>
wrote:

> Updating the site isnt actually hard at all, but its surprising how
> often people still manage not to get round to it for one reason or
> another. I recall on numerous occasions of asking about site updates
> for otherwise complete releases, sometimes weeks later. The last time
> adding a 'next release date' on the site was discussed, I recall
> observing that the dates on the cited exemplar project site were
> actually all stale at the time and in the past by some amount up to a
> year. To me, dates or those with no actual substance behind them are
> actually often just misleading and worse than just not suggesting
> dates. Many projects dont list dates, perhaps even 'most'.
>
> I dont think a vague quarterly promise is really going to be any
> better based on prior patterns. Many releases have been way over or
> way under that frequency, and since it seems in general no specific
> schedule is usually being worked to it I would avoid generally
> suggesting it is. I would just try doing more frequent, smaller,
> releases at points it is appropropriate to the work actually going on
> in the repo.
>
> Robbie
>
> On Tue, 1 Feb 2022 at 18:12, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
> >
> > Hi Justin,
> >
> > I think it’s not a huge effort compare to what we already do at each
> release (updating the website).
> >
> > For instance, for Karaf, it’s pretty quick to update website and release
> schedule at each release cycle.
> >
> > I already proposed regular release cycle in the past (as best effort).
> >
> > I would agree with both: regular release cycle (quarterly) + some
> details (at least for “major” releases) on website.
> >
> > Regards
> > JB
> >
> > > Le 1 févr. 2022 à 18:32, Justin Bertram <jb...@apache.org> a écrit
> :
> > >
> > > Generally speaking, I'm against anything that will require more
> maintenance
> > > of the website. History indicates that the community is somewhat weak
> in
> > > this area.
> > >
> > > Correct me if I'm wrong, but from what I can tell we've never
> consistently
> > > scheduled releases. Also, given the Apache Way with the release voting
> > > process we can only be precise about when a release will go up for a
> vote.
> > > There's no way to actually guarantee a release date. Why not have
> > > consistent, time-boxed (e.g. quarterly) releases? That would solve a
> > > handful of problems:
> > >
> > > - users could depend on a general cadence for releases
> > > - the website could simply outline the release cadence which would
> > > alleviate the need for maintenance
> > > - it would reduce the communication necessary to coordinate a release;
> a
> > > release manager could simply step up and perform the release when the
> time
> > > comes
> > >
> > > Obviously we can still have "ad hoc" releases as necessary (e.g. due
> to a
> > > security issue).
> > >
> > > Thoughts?
> > >
> > >
> > > Justin
> > >
> > > On Tue, Feb 1, 2022 at 6:47 AM Tim Bain <tb...@alumni.duke.edu> wrote:
> > >
> > >> Would it be worth the effort to create and then maintain a page that
> lists
> > >> the planned timeline of upcoming releases for both 5.x and Artemis?
> There
> > >> have been a lot of questions about upcoming plans in the wake of the
> Log4J
> > >> CVE, but even during normal times we get occasional questions here
> about
> > >> upcoming plans, and that's just the users who bother to sign up for
> the
> > >> mailing list so there could well be more who look for that info but
> don't
> > >> post to ask.
> > >>
> > >> The downside is that once we create a page for that content we'll
> have to
> > >> be diligent about updating it (including publishing updates when
> something
> > >> slides back a bit), otherwise what's the point. I'm not sure if the
> folks
> > >> who would have to do the ongoing work on this think it's worth the
> effort,
> > >> but I wanted to throw it out for consideration.
> > >>
> > >> Tim
> > >>
> >
>

Re: Upcoming releases

[Robbie Gemmell <ro...@gmail.com>]

Updating the site isnt actually hard at all, but its surprising how
often people still manage not to get round to it for one reason or
another. I recall on numerous occasions of asking about site updates
for otherwise complete releases, sometimes weeks later. The last time
adding a 'next release date' on the site was discussed, I recall
observing that the dates on the cited exemplar project site were
actually all stale at the time and in the past by some amount up to a
year. To me, dates or those with no actual substance behind them are
actually often just misleading and worse than just not suggesting
dates. Many projects dont list dates, perhaps even 'most'.

I dont think a vague quarterly promise is really going to be any
better based on prior patterns. Many releases have been way over or
way under that frequency, and since it seems in general no specific
schedule is usually being worked to it I would avoid generally
suggesting it is. I would just try doing more frequent, smaller,
releases at points it is appropropriate to the work actually going on
in the repo.

Robbie

On Tue, 1 Feb 2022 at 18:12, Jean-Baptiste Onofre <jb...@nanthrax.net> wrote:
>
> Hi Justin,
>
> I think it’s not a huge effort compare to what we already do at each release (updating the website).
>
> For instance, for Karaf, it’s pretty quick to update website and release schedule at each release cycle.
>
> I already proposed regular release cycle in the past (as best effort).
>
> I would agree with both: regular release cycle (quarterly) + some details (at least for “major” releases) on website.
>
> Regards
> JB
>
> > Le 1 févr. 2022 à 18:32, Justin Bertram <jb...@apache.org> a écrit :
> >
> > Generally speaking, I'm against anything that will require more maintenance
> > of the website. History indicates that the community is somewhat weak in
> > this area.
> >
> > Correct me if I'm wrong, but from what I can tell we've never consistently
> > scheduled releases. Also, given the Apache Way with the release voting
> > process we can only be precise about when a release will go up for a vote.
> > There's no way to actually guarantee a release date. Why not have
> > consistent, time-boxed (e.g. quarterly) releases? That would solve a
> > handful of problems:
> >
> > - users could depend on a general cadence for releases
> > - the website could simply outline the release cadence which would
> > alleviate the need for maintenance
> > - it would reduce the communication necessary to coordinate a release; a
> > release manager could simply step up and perform the release when the time
> > comes
> >
> > Obviously we can still have "ad hoc" releases as necessary (e.g. due to a
> > security issue).
> >
> > Thoughts?
> >
> >
> > Justin
> >
> > On Tue, Feb 1, 2022 at 6:47 AM Tim Bain <tb...@alumni.duke.edu> wrote:
> >
> >> Would it be worth the effort to create and then maintain a page that lists
> >> the planned timeline of upcoming releases for both 5.x and Artemis? There
> >> have been a lot of questions about upcoming plans in the wake of the Log4J
> >> CVE, but even during normal times we get occasional questions here about
> >> upcoming plans, and that's just the users who bother to sign up for the
> >> mailing list so there could well be more who look for that info but don't
> >> post to ask.
> >>
> >> The downside is that once we create a page for that content we'll have to
> >> be diligent about updating it (including publishing updates when something
> >> slides back a bit), otherwise what's the point. I'm not sure if the folks
> >> who would have to do the ongoing work on this think it's worth the effort,
> >> but I wanted to throw it out for consideration.
> >>
> >> Tim
> >>
>

Re: Upcoming releases

[Jean-Baptiste Onofre <jb...@nanthrax.net>]

Hi Justin,

I think it’s not a huge effort compare to what we already do at each release (updating the website).

For instance, for Karaf, it’s pretty quick to update website and release schedule at each release cycle.

I already proposed regular release cycle in the past (as best effort).

I would agree with both: regular release cycle (quarterly) + some details (at least for “major” releases) on website.

Regards
JB

> Le 1 févr. 2022 à 18:32, Justin Bertram <jb...@apache.org> a écrit :
> 
> Generally speaking, I'm against anything that will require more maintenance
> of the website. History indicates that the community is somewhat weak in
> this area.
> 
> Correct me if I'm wrong, but from what I can tell we've never consistently
> scheduled releases. Also, given the Apache Way with the release voting
> process we can only be precise about when a release will go up for a vote.
> There's no way to actually guarantee a release date. Why not have
> consistent, time-boxed (e.g. quarterly) releases? That would solve a
> handful of problems:
> 
> - users could depend on a general cadence for releases
> - the website could simply outline the release cadence which would
> alleviate the need for maintenance
> - it would reduce the communication necessary to coordinate a release; a
> release manager could simply step up and perform the release when the time
> comes
> 
> Obviously we can still have "ad hoc" releases as necessary (e.g. due to a
> security issue).
> 
> Thoughts?
> 
> 
> Justin
> 
> On Tue, Feb 1, 2022 at 6:47 AM Tim Bain <tb...@alumni.duke.edu> wrote:
> 
>> Would it be worth the effort to create and then maintain a page that lists
>> the planned timeline of upcoming releases for both 5.x and Artemis? There
>> have been a lot of questions about upcoming plans in the wake of the Log4J
>> CVE, but even during normal times we get occasional questions here about
>> upcoming plans, and that's just the users who bother to sign up for the
>> mailing list so there could well be more who look for that info but don't
>> post to ask.
>> 
>> The downside is that once we create a page for that content we'll have to
>> be diligent about updating it (including publishing updates when something
>> slides back a bit), otherwise what's the point. I'm not sure if the folks
>> who would have to do the ongoing work on this think it's worth the effort,
>> but I wanted to throw it out for consideration.
>> 
>> Tim
>> 

Re: Upcoming releases

[Justin Bertram <jb...@apache.org>]

Generally speaking, I'm against anything that will require more maintenance
of the website. History indicates that the community is somewhat weak in
this area.

Correct me if I'm wrong, but from what I can tell we've never consistently
scheduled releases. Also, given the Apache Way with the release voting
process we can only be precise about when a release will go up for a vote.
There's no way to actually guarantee a release date. Why not have
consistent, time-boxed (e.g. quarterly) releases? That would solve a
handful of problems:

 - users could depend on a general cadence for releases
 - the website could simply outline the release cadence which would
alleviate the need for maintenance
 - it would reduce the communication necessary to coordinate a release; a
release manager could simply step up and perform the release when the time
comes

Obviously we can still have "ad hoc" releases as necessary (e.g. due to a
security issue).

Thoughts?


Justin

On Tue, Feb 1, 2022 at 6:47 AM Tim Bain <tb...@alumni.duke.edu> wrote:

> Would it be worth the effort to create and then maintain a page that lists
> the planned timeline of upcoming releases for both 5.x and Artemis? There
> have been a lot of questions about upcoming plans in the wake of the Log4J
> CVE, but even during normal times we get occasional questions here about
> upcoming plans, and that's just the users who bother to sign up for the
> mailing list so there could well be more who look for that info but don't
> post to ask.
>
> The downside is that once we create a page for that content we'll have to
> be diligent about updating it (including publishing updates when something
> slides back a bit), otherwise what's the point. I'm not sure if the folks
> who would have to do the ongoing work on this think it's worth the effort,
> but I wanted to throw it out for consideration.
>
> Tim
>

Re: Upcoming releases

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

And by the way, this page should mention some important notes (like JDK 
version supported, log4j versions, Spring version, ...).

Regards
JB

On 01/02/2022 13:47, Tim Bain wrote:
> Would it be worth the effort to create and then maintain a page that lists
> the planned timeline of upcoming releases for both 5.x and Artemis? There
> have been a lot of questions about upcoming plans in the wake of the Log4J
> CVE, but even during normal times we get occasional questions here about
> upcoming plans, and that's just the users who bother to sign up for the
> mailing list so there could well be more who look for that info but don't
> post to ask.
> 
> The downside is that once we create a page for that content we'll have to
> be diligent about updating it (including publishing updates when something
> slides back a bit), otherwise what's the point. I'm not sure if the folks
> who would have to do the ongoing work on this think it's worth the effort,
> but I wanted to throw it out for consideration.
> 
> Tim
> 

Re: Upcoming releases

[Jean-Baptiste Onofré <jb...@nanthrax.net>]

Hi Tim,

That's a good idea (and it's what we are doing on others projects like 
Karaf and Camel).

If there's no objection, I will do the ActiveMQ one.

Regards
JB

On 01/02/2022 13:47, Tim Bain wrote:
> Would it be worth the effort to create and then maintain a page that lists
> the planned timeline of upcoming releases for both 5.x and Artemis? There
> have been a lot of questions about upcoming plans in the wake of the Log4J
> CVE, but even during normal times we get occasional questions here about
> upcoming plans, and that's just the users who bother to sign up for the
> mailing list so there could well be more who look for that info but don't
> post to ask.
> 
> The downside is that once we create a page for that content we'll have to
> be diligent about updating it (including publishing updates when something
> slides back a bit), otherwise what's the point. I'm not sure if the folks
> who would have to do the ongoing work on this think it's worth the effort,
> but I wanted to throw it out for consideration.
> 
> Tim
>