OK, this is really going to come across as me being an asshole, but, why on earth are we looking to spend such an excessive amount of time to write scripts to do things we already have scripts to do and automate a process that takes maybe 2 minutes with an extension?

I have had to argue this in quite a few places, but IMO, you cannot have a release script that fully automates everything from tagging to upload. With the way GitHub works, this means you must push your release tag to the repo (and the working branch); with a security release, this means the security issues and fixes are actually disclosed before announcement of a release. Keeping this concern in mind should not make a fully automated system a viable option.

Also, I'm going to be completely blunt as someone who has coordinated releases around large distributed products and very small extensions. The process that you are looking to automate here is typically a 3-to-5-minute task at the most (change version, commit and tag version change, push tag to repo, package distribution, upload to download source). When I have turned around quick releases for the CMS, I had it down to a total 90-minute task for a combined 2.5 and 3.3 release and I kid you not 75 minutes of that were spent on testing the issues we were fixing were actually fixed and working on the announcements and updating pages; this automated process would have saved next to no time in that.

If you all want to automate all the things, go for it. But to be perfectly honest with you, it won't save you any time and it won't make more people capable of or willing to issue a release.

I fully understand. I really doubt we can automate the process. But the things that can be done let's do it. Is not one script to rule them all but several small scripts that assist a manual workflow.

For example Package the extension as we do now with the PHING script is an example. Or given the tag already created: create the release in github, upload the packaged zip to the release, and write the changelog (draft version to be manually cleaned), is something feasible and useful, isn't it?

It doesn't have to be about time saving only. Sometimes one automates things to save tedious work and reduce chance of missing something.

agreed, when is something that I don't do often I hardly recall all the steps. Having a guide helps

@mbabker At least in my world, the idea lives that a CMS release is a trip into the abyss and if you are lucky you get back. From what I understand from your writing is that a CMS release takes at max 5 minutes. If that is the case, I wonder what all the doom scenarios are doing, flying around :)

So here's the thing on the changelog aspect of it. If you make the changelog just the commit log or pull request titles as we historically have, then sure, you can automate all of that. The problem is that more often than not, that stuff is meaningless to the non-developers (I've had to have that beaten into me a few times). So unless we get a lot more strict about commit messages, issue titles, and categorizing issues, you'll still just as much time editing the auto-generated log to make it user friendly as you would just manually compiling it. Quite frankly, if it weren't for me editing them, I would never look at the CMS release announcements because they are seriously just some boilerplate crap with a bunch of thank you's and the links to the packages.

The actual process of packaging the CMS for release, from the time you run php build/build.php to the time CMS users could consume the update via the update component is seriously like 15 minutes max (have to account for the CDN the update server is behind and its refresh rate). For a Tuesday release, I usually started Sunday afternoon inputting all of the data for the support stuff (names for the thank you blocks, links to issue lists, security announcements, etc.) into the various sites; drafting the main announcement usually started up to a week before the release and coordinated with other PLT members and marketing at a minimum. The most time consuming aspect of our releases is in processes that you just can't automate unless we are fine with continuing to put out posts that are generic copy/paste things.

@javigomez I think we can close this as done. Weblinks RoboFile / JoRobo offers all features asked for.

No objections received so I'm closing this one. Thanks for the discussion everyone.