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 <robbie.gemm...@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 <j...@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 <jbert...@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 > > >> > > >
