Problem/Motivation

Currently five kinds of releases are posted to the front page:

1. Drupal 7 security releases.
2. Drupal 7 bug fix releases.
3. Drupal 8 security releases
4. Drupal 8 patch releases (bug fixes)
5. Drupal 8 minor release betas/release candidates.

Preparing the release notes and front page posts is the most time-consuming aspect of preparing a core release, and it is also work which has to be done within the 48 hours the release is actually being put out. This generally requires co-ordination between me, xjm and other committers across (at the moment) four time zones and three continents.

For the release notes, we've streamlined this as much as we can at the moment and the bits that can't be streamlined need input from core committers. But for the front page posts it's an entire additional step which does not really need special handling.

Additionally, for me personally the releases being in the news feed is not optimal. For example in the past two weeks there have already been four of these kinds of releases - the only one we didn't have was a 7.x bug fix release. If we do a node for each release type, it's just going to look cluttered and repetitive. For this reason I never actually do the front page posts, so either they don't happen, or xjm does them - which is not really ideal either.

There is quite a significant change in frequency of releases with 8.x compared to 7.x. 8.x both has considerably more frequent releases, as well as much more considerable work going into each release - there were over 120 commits in the past month for example. So this is creating noticeable overhead which is draining time from actually reviewing and committing patches, not to mention release-time specific tasks like making sure it's actually ready to go out, on a regular basis.

Proposed resolution

I can see two obvious options, Gabor suggested a third option:

1. Automate the front page posts based on a template, to be published when the release node goes out.

2. Since the frequency of releases means there will pretty much always be a core release on the front page, reconsider the decision to not have some kind of 'download'/'core releases' block on the front page. Really, we don't need an actual post every time - the release nodes handle that, we just need information on the front page about what the most recent releases are and maybe the date they were put out. None of this prevents a front page post if a release is 'special', just saves doing it every time when it's not particularly interesting information.

3. Don't do this at all, because it's repetitive posting nearly the same thing every week.

For me the important thing is I do not want to be doing this manually every month for the next few years - since it really is not related to actually getting the release out, it's Drupal.org content/marketing.

Remaining tasks

None

User interface changes

API changes

Data model changes

Comments

catch created an issue. See original summary.

Gábor Hojtsy’s picture

Since when are we doing front page posts for all releases? It has certainly not been the case historically. We used the front page for high impact stuff, eg. 8.0.0, 8.1.0, the last D6 release, etc. would get there but not every other release (even security releases).

dddave’s picture

We have the core release announcements in the news since a long while now. ;)
As a new core release, even if not a "special" one, is very revelant to the heart of what Drupal is about I personally think these news belong onto the frontpage and the news feed.

it's Drupal.org content/marketing

Agreed. And as such it is important but shouldn't be your work to do. The Assoc has paid staff for this. Just sayin'.

Gábor Hojtsy’s picture

But is it marketing if there is a new release post (or more than one) every second Wednesday, pushing down all other messaging that the news section may have and practically making it useless for trying to announce anything else that needs to last? (Or to make everything else need to coordinate times so they have some days of visibility at least?).

To play the devil's advocate, why are we announcing releases only and not all commits one by one? :P Those are even more the heart of what Drupal is about (if releases are).

catch’s picture

Issue summary: View changes

@Gabor this is why I prefer option #2 from the issue summary. I'd also be fine with not posting every release to the front page, which is option #3 I guess - added to issue summary.

dddave’s picture

To play the devil's advocate, why are we announcing releases only and not all commits one by one? :P Those are even more the heart of what Drupal is about (if releases are).

;)

I see your point but I'd counter that Drupal core is "our" product and we should proudly and prominently communitcate progress/innovation/improvements.

But we certainly agree that leaving it to the core maintainers is not a sustainable solution.

Gábor Hojtsy’s picture

AFAIS we can be proud without putting every small accomplishment in people's faces. Nowadays Drupal releases as often as your phone's gmail app. Gmail does not do a big deal about their frequent releases and the bugs they fixed in each on their front page either. An added bonus is that the actual accomplishment became a bigger bang then, not a "oh, another Drupal release announcement, who cares" :)

tvn’s picture

Assigned: Unassigned » tvn

I am setting up a meeting in the next few weeks with the representatives of the core team, Security team and our Association team to talk this through. Will update this issue afterwards.

Personally I like some variation of #2. Well-written, editorial posts announcing big important releases should definitely happen. We can find a different way to announce minor releases in between.

xjm’s picture

Since when are we doing front page posts for all releases? It has certainly not been the case historically. We used the front page for high impact stuff, eg. 8.0.0, 8.1.0, the last D6 release, etc. would get there but not every other release (even security releases).

Well, this was done throughout the D7 cycle. It was documented in https://www.drupal.org/core/maintainers/create-core-release that a front page post is a required step, and if you look back through the front page forum history, there are posts for every release of D6 and D7 as far back as I went. So as far as I ever knew, it was just the policy.

Edit: Yes, I am pretty sure there is a front page post for every single patch release of D7 back to 7.7 7.14 or so. So not sure why there is incredulity here as it's been going on for at least 5 4 years. Edit: And also, following the policy, I have created a front page post for every patch release of D8.

Edit: To be clear, I do not want these posts. Just saying that it's certainly not also something catch or I conjured; we inherited it.

xjm’s picture

So I think we need feedback from @webchick and @David_Rothstein in here, because if we are going to change things from the best practice that was adopted for D7, we should make sure we've addressed the reasons that best practice was adopted in the first place.

xjm’s picture

I am setting up a meeting in the next few weeks with the representatives of the core team, Security team and our Association team to talk this through. Will update this issue afterwards.

Maybe we should consider inviting those stakeholders to participate on this issue, so we don't have to schedule a meeting for timezones across three continents? Personally, I'd be glad to stop having meetings about this and just discuss it in the public issue queue unless it gets blocked, and then just update the handbook page with the consensus. I will follow the consensus, but I would really like the consensus to involve less overhead, both in terms of preparing releases and in terms of not having to attend meetings for something outside my area of expertise.

David_Rothstein’s picture

A couple comments:

  1. As far I know the front page announcements for every single core release have been going on since time immemorial. Here's the Drupal 4.3.1 (bugfix release) front-page announcement from December 2003: https://web.archive.org/web/20031219200215/http://drupal.org :) I suspect they used to fill the role of Update Status (before Update Status existed) which does make them less important now.
  2. 2. .... Reconsider the decision to not have some kind of 'download'/'core releases' block on the front page. Really, we don't need an actual post every time - the release nodes handle that, we just need information on the front page about what the most recent releases are and maybe the date they were put out.

    I think the intended audience for the front page posts is different than for the release notes (generally a less technical audience). That said, most of what's in the front page posts (for example the entire right column) is boilerplate text that doesn't change from release to release. And the text hasn't been rewritten in years and could stand to be shortened.

    So if there was a block on the front page that:

    • Had a direct link to the latest releases
    • Showed the release date and explained if it was a security release or not
    • Had a link to some generic "more information" page which had the security/bug/etc info that's currently repeated on each front page post (and this page could be linked to from the release notes also)

    Then I agree that could be a good replacement for the front page posts.

  3. I do think it's nice that these announcements wind up on Drupal Planet though (especially for security releases)... not sure if there's a good way that could be preserved.
  4. There is quite a significant change in frequency of releases with 8.x compared to 7.x. 8.x ... has considerably more frequent releases

    Do you think this will continue though? For Drupal 7, @webchick did one bugfix release a month for a while (which is basically what Drupal 8 is doing now) but she slowed it down to once every 2-3 months within the first year (after things had stabilized), and since then I've tried not to do it more often than every 3 months when possible. I think slowing down the frequency as the code becomes more stable is normal and probably a good thing - performing Drupal core updates is a pain in the neck for site administrators :)

    Of course security releases mean the actual frequency is increased compared to the above, and because of that there still will be times when there are 2 releases a month (which under the current system does mean a concentration of front-page posts during those months).

  5. Preparing the release notes and front page posts is the most time-consuming aspect of preparing a core release, and it is also work which has to be done within the 48 hours the release is actually being put out.

    In my experience the release notes are time-consuming, but the front page posts aren't (because it's all boilerplate text anyway) and could be done earlier than 48 hours beforehand if you really wanted to. I usually just copy/pasted a previous one and then did a find/replace on the version numbers which only took a few minutes. And I thought @xjm came up with some kind of script recently that made it even faster?

    So it would be nice if it were fully automated, but in my experience the front page posts aren't really the bottleneck in getting out a core release. (Off-topic, but I think the big time-saver would be improved tools/integration between security.drupal.org and drupal.org.)

David_Rothstein’s picture

I was curious what other projects do for this so I looked at WordPress and Joomla. It looks like both actually do announce every release via a front page post (like Drupal currently does).

WordPress example:
https://wordpress.org/news/2016/02/wordpress-4-4-2-security-and-maintena...

Joomla example:
https://www.joomla.org/announcements/release-news/5644-joomla-3-4-8-rele...

Both of these announcements are/were linked via a teaser from the front page.

catch’s picture

Do you think this will continue though?

Drupal 7 releases slowed down after a few months because activity gradually shifted to Drupal 8 over that year.

Given Drupal 9 isn't going to be open for some time, this is unlikely to happen in quite the same way. I'm also at least at the moment hoping we can find a way to keep the 9.x development cycle short, so there's not too much of a gap between the branch opening and 9.0.0. With all that, I'd expect regular releases for some time. Even if we did zero patch releases and zero security releases, we'd still have two minors, one or two betas and one or two rcs per year, which is up to six releases per year.

I usually just copy/pasted a previous one and then did a find/replace on the version numbers which only took a few minutes.

That's the definition of something that should not be done at least once per month by a human. Also it's not quite as simple as that - do we put Drupal 7 and 8 in the same posts or different ones? What about patch releases vs. the beta? Regardless of those decisions, what happens if we don't release those 2-3 things simultaneously?

David_Rothstein’s picture

I guess frequency of releases != frequency of commits, was my main point.

But I do agree there are still potentially a lot of these announcements, even if the release frequency were lower.

Gábor Hojtsy’s picture

Yeah while it may be old practice that we do this for every release (sorry I did not notice), we did not use to release every two weeks from 2 branches of Drupal at least. And now we are releasing from 3 possibly at once: Drupal 7, Drupal "8.current" and Drupal "8.upcoming".

xjm’s picture

Right, not sure if it was stated earlier here on the issue, but @tvn said that it was not good content strategy to have combined front page posts for the D7 and D8 releases, so fixing that according to the DA's recommendation would mean that we would have even more frequent/redundant posts than we already do if we keep doing them.

I do not anticipate any patch release window that does not include a D8 patch release any time within the next year, barring some special circumstance. So in a year that might be something like: 12 D8 patch releases, 2 D8 minors, 4 D8 betas, 3 D8 RCs, let's say maybe 4 D8 or combined sec releases and 4 D7 bugfix releases. That's 29 front page posts. Last year there were about 24 front page posts not related to releases. So this would mean that this year the frontpage might have more boilerplate content than actual content. :)

Gábor Hojtsy’s picture

Yeah I did not have those numbers but I had the same feeling as @xjm in #17. Do we want the home page to be a release feed pretty much obscuring everything else that we want to communicate?

xjm’s picture

tvn’s picture

Yesterday mlhess, Gabor Hojtsy, bradleyfields, and myself had a quick chat about this. Here is the resolution we propose:
1. We do front page post only for the following releases:
a. Security releases (all) - maximum 12 per year if one happens every month, should be less
b. Minor releases (8.x, 7.x) - maximum 6 posts (2 for D8, 4 for D7)
c. Major releases (of course)

Announcements for beta and RC releases go into g.d.o/core, as they are aimed at insider community audience more so than on newcomers and evaluators.

All front page posts will be tweeted promptly from @drupal. We'll work on improving communication between core/security team and DA staff to make sure this happens on time.

Posts about security releases are published by security team members based on pre-approved template. One post can cover security releases for multiple major versions when they are mostly identical.

Posts about minor releases will follow a template, but will include unique copy and go through editorial review. One post covers one major version release.

Think this covers all we talked about. bradleyfields will follow up with proposed modifications for the front page post template for releases.

xjm’s picture

Announcements for beta and RC releases go into g.d.o/core, as they are aimed at insider community audience more so than on newcomers and evaluators.

My one concern about this is that g.d.o/core does not have nearly enough visibility for (e.g.) a release candidate. We do actually want normal site owners who probably do not follow g.d.o/core to read the announcement about the release candidate for 8.1.0, because it is important that they start testing their upgrade from 8.0.x. The RC of 8.1.0 is also an EOL announcement for 8.0.x.

Gábor Hojtsy’s picture

So you propose the draw the line between RC and beta then? Does that sound good?

xjm’s picture

I think we would certainly want to post on the d.o frontpage blog about RC1, but not about RC2.

Betas are more for a developer audience, so even with the curernt policy for beta1 I only posted about it on g.d.o/core (although I went back and forth about whether enough people would see it at the time). But I don't think the front page audience is right for a beta either.

xjm’s picture

Another thing I don't see covered in #20 is how we communicate the availability of new patch releases instead when we get rid of the noisy/boilerplate frontpage posts. Other than that and the bit about RC1 specifically, it looks good to me.

In the longer term we need to fix the visibility of g.d.o/core, and it looks like @tvn has that on the roadmap in https://www.drupal.org/drupalorg/blog/communicating-better.

catch’s picture

Yeah agreed with #21/#24. RC1 is a 'get ready' announcement that's in many ways more important than the actual .0 release (at least as far as it helps the 8.1.0 actually be a good one and prepares people to think about upgrading to it in advance).

Also that we should still have some way to communicate the most recent releases - we don't want to direct people to 8.1.0 from the front page when 8.1.4 is out, but that's the quickest route from the front page to an actual release at the moment due to the lack of download button.

bradleyfields’s picture

From the homepage, there are 3 kinds of ways to get to the latest D8 release (patches included) within 2 clicks, right? "Get Started," "Download & Extend," or one of the links to /8.

With the current iteration of the homepage, it seems there's only one likely scenario in which a link to 8.1.x would be on the homepage while a newer release was out. That'd be if 8.1.x's release announcement were still in the News section while 8.1.x+n were out. But between community spotlights, "What's new on Drupal.org" posts, security announcements, etc., the News content should cycle often enough to avoid that.

For patches and RCs, though: we should probably see whether data supports the idea that homepage inclusion really does get them the best exposure. For example, after a quick glance at analytics, more than 20% of homepage clicks since Nov 19 have been on "Download & Extend." There may be equal or better options for traffic, like getting patch and RC announcements into Planet via blog post and promoting them multiple times via social media.

Gábor Hojtsy’s picture

@bradleyfields: Yeah I don't think anyone is proposing to post patch releases (which are not security releases) on the frontpage anymore. So that is good :) I understand better now that an RC may be an even bigger milestone than a .x release, see https://www.drupal.org/core/release-cycle-overview#minor. Copying the image here for discussion:

Basically RC1 signals that the support time of 8.prior.x is almost over and 8.next.x is coming, so people need to be prepared if they want to ensure they are on a platform that is bug/security fix supported. So its a pretty significant point in time. Its true that the actual support EOL is at the release of the next minor release, but we are trying to prepare people.

bradleyfields’s picture

Oh, sure. Definitely agree re: RCs. Was just acknowledging the note in #24 re: communicating the availability of new patch releases if not via posts to the front.

Separately, updating wireframes today. I'll circulate them for some Assoc. insight, and then if all goes well, we can share them for feedback here on Monday.

xjm’s picture

Status: Active » Needs review

So, I went ahead and adopted this for 8.0.6 and did not create a separate frontpage post for it. There are two other ways we are communicating about 8.0.6 in particular:

  1. I added this note to the top of the 8.0.5 frontpage post:

    Update: Drupal 8.0.6 is now available. We will no longer post front page announcements for every monthly bugfix release, but you can always follow the Drupal project page to find the latest release.

  2. Since 8.0.6 is the final bugfix release for 8.0.x and sites must upgrade to 8.1.0 after it, it will also be mentioned in the frontpage post about the 8.1.0 RC that will be coming out today.

We should consider whether we add a note to the 8.1.0 frontpage post about how future monthly releases will be communicated since it won't be on the frontpage anymore. All things considered, this is a good time to adopt the new strategy.

Gábor Hojtsy’s picture

Yay for adopting the new system. :) Thanks!

We should consider whether we add a note to the 8.1.0 frontpage post about how future monthly releases will be communicated since it won't be on the frontpage anymore.

Not sure, that post will include lots of info already. Maybe at the very end.

xjm’s picture

Oh, a related question that came up while I was rolling 8.0.6. Currently the practice is to have the following path aliases (using 8.0.5 as an example):

  • /drupal-8.0.5 for the frontpage post.
  • /drupal-8.0.5-release-notes for the release node itself.

Going forward, some releases will have both a release node and a frontpage post, whereas most will have only the release node. What path aliases should we use then?

For 8.0.6, I used /drupal-8.0.6-release-notes but also added a redirect for /drupal-8.0.6 because I wasn't sure what else to do.

David_Rothstein’s picture

From the homepage, there are 3 kinds of ways to get to the latest D8 release (patches included) within 2 clicks, right? "Get Started," "Download & Extend," or one of the links to /8.

Sadly, no. I think those are all at least 3 clicks to get to the actual file download (and in most cases 4). Whereas with the front page announcement it is 2 clicks from the homepage to the actual file.

The links are unfortunately worded in a way that makes it look like you will get there in fewer clicks than it actually takes :(

So it would be great to replicate the two-click experience via the actual "Download & Extend" route => especially because every other comparable CMS whose homepage I've seen gives you a way to download with no more than 2 clicks.

tvn’s picture

Thanks for adopting the new system, Jess.

Regarding the urls. We plan to introduce a standard path alias for all releases for all projects in the future. The pattern will be: d.o/project/[title]/releases/[version], where 'd.o/project/[title]/releases' is a list of all releases for a project (currently e.g. https://www.drupal.org/node/3060/release)
So you could start using this pattern for release nodes now, e.g. d.o/project/drupal/releases/8.0.5

For release announcements (posts), the url should be based on post title and location. If it is published in News and announcements forum, the url should be d.o/news/drupal-8.0.5-released (or whatever is the actual title of the post). Once those posts move to d.o/blog, urls there will be generated automatically (and will be d.o/blog/drupal-8.0.5-released).

Top level urls are generally used for top level sections in the IA and special landing pages only, e.g. /support, /8 for D8 release, etc.

xjm’s picture

tvn’s picture

Thanks, Jess. I edited the page a bit, and listed all the types of release announcement we agreed to create and promote to front there. Hope I got it right about RCs.

drumm’s picture

We plan to introduce a standard path alias for all releases for all projects in the future. The pattern will be: d.o/project/[title]/releases/[version]

I’m working on this today.

  • drumm committed 0428585 on 7.x-3.x
    Issue #2680023: Update release paths to project/{project short name}/...
drumm’s picture

The new release node paths are now set up for new releases.

drumm’s picture

where 'd.o/project/[title]/releases' is a list of all releases for a project (currently e.g. https://www.drupal.org/node/3060/release)

I’ll be working on this today. Initially, the path aliases will show up as project nodes are saved.

  • drumm committed 1d04e04 on 7.x-3.x
    Issue #2680023: Update release listing paths to project/{project short...
drumm’s picture

The new release listing paths are now set up for new & updated projects.

David_Rothstein’s picture

I made a few changes to the handbook page today (https://www.drupal.org/node/2715621/revisions/view/9640569/9781533):

  1. Clarified that we'll do a maximum of 2 non-security posts for Drupal 7 per year (rather than 4), i.e. same as for Drupal 8 (no need to do front-page posts for a regular Drupal 7 bugfix release if we don't for Drupal 8).
  2. Clarified that an announcement for a joint D7+D8 security release needs to break the "only one green button call-to-action rule" since we need download links for each release.

Some of this came from putting together today's front page post (https://www.drupal.org/blog/drupal-8-1-3-and-7-44), which I believe was the first time we used the new procedure for a security release announcement.

Gábor Hojtsy’s picture

All makes sense to me, yay, thanks David.

tvn’s picture

Thanks David!

xjm’s picture

Now that we've had a chance to see this in practice, I wonder if we should not create front page posts for security releases, and instead publish the SA directly to the frontpage. Otherwise, it ends up with either redundant posts (if we promote the SA as well), or multiple clicks (since the security post is mostly just wrapper for the SA).

Compare:
https://www.drupal.org/blog/drupal-8-1-7-released
https://www.drupal.org/SA-CORE-2016-003

Since the release notes also need to contain specific details that are more specific than belong in the SA (see https://www.drupal.org/project/drupal/releases/8.1.7), having some information in three places gets confusing (even for me when I helped write all three).

tvn’s picture

I checked with bradleyfields and mlhess, the idea (#18) makes sense to all of us. Having 3 pieces of content about the same thing does look like a slight overkill.

David_Rothstein’s picture

I don't think SAs are usually written with a front page audience in mind. And they're missing the general "call to action" (green download button, wording which puts the release in context, etc) that front page posts have.

So I don't think this is a good idea unless we want to really change the way SAs are written.

There shouldn't be duplicate front-page posts though. (I am not sure why https://www.drupal.org/SA-CORE-2016-003 was promoted to the front page.)

xjm’s picture

There shouldn't be duplicate front-page posts though. (I am not sure why https://www.drupal.org/SA-CORE-2016-003 was promoted to the front page.)

We had previously agreed to demote the less informative PSA from the frontpage in favor of the SA. (Also, the title "Drupal 8.1.7 released" did not really convey any urgency. We could of course change our titles for those posts.) In this case, the SA also included information that also affected non-Drupal 8 sites, even though the sec release itself was only for D8. So in this case I definitely think the SA needed to be promoted.

And they're missing the general "call to action" (green download button, wording which puts the release in context, etc) that front page posts have.

We do already have a section at the end of SAs for contact and more information. It would be totally reasonable to trim down the boilerplate context information that is in the frontpage post template and include it there instead for core releases. A sidebar action button linking to the relevant release node(s) also would seem valuable to me (for any SA really, not just core ones).

tvn’s picture

Project: Drupal.org customizations » Drupal.org content
Version: 7.x-3.x-dev »
Component: Code » Front page promotion

Moving to the proper queue, as this is content policy question, rather than a custom code for Drupal.org question. Also some new feedback here #2818667: Should security updates be on the homepage of Drupal.org?.

catch’s picture

This came up again on #2818507: Update home page to point to 8.2.1. We had to do an unscheduled 8.2.1 release due to an unexpected regression. This meant that the 8.2.0 post is still the top item on the front page, and there's nowhere linking to the 8.2.1 release.

drumm’s picture

Assigned: tvn » Unassigned
Issue summary: View changes
lizzjoy’s picture

Issue summary: View changes
Status: Needs review » Fixed

I updated information on how to request access to post on /about/blog at https://www.drupal.org/core/maintainers/create-release-announcement is accurate, so I believe this issue is now fixed.

lizzjoy’s picture

I updated information on how to request access to post on /about/blog at https://www.drupal.org/core/maintainers/create-release-announcement is accurate, so I believe this issue is now fixed.

apaderno’s picture

I am giving credits to the users who participated in this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.