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