Support

The maturity is tagged in the Release itself. The generated update channel will contain all published releases within the same Category, each one tagged with the stability tag (alpha, beta, rc, stable) of the ARS Release record.

Now, how can your client's site know which one to install? This is something you define in Extensions, Extension Manager, Options, Minimum Stability. Only updates of the selected or higher stability will be shown to the user as being available.

Maturity handling was added in Joomla! 3.4.0. Earlier versions don't have that option. Apart from that I can't think of anything else.

Do you mean the new tags in the xml file that sits on the updateserver?

Yes.

I tried that but when the site is set to beta the beta does not get detected.

Sorry, I can't provide generic Joomla! support. I can only tell you that Joomla! 3.4.0 and later will respect these tags as long as you have set a minimum stability of release candidate or stable in Extensions, Manage Extensions, Options.

Another recent issue: I looked up the docs but could not figure out where I find the link (to the update pkg) that goes into that xml file that sits on the updateserve. Any hint?

Akeeba Release System, Update Streams. See the Links column per the documentation.

Another recent issue: The docs say that in bleeding edge the items inherit the ACL from the catgory but in my installation that never works. I always have to go into the ARS backend items page and manually change the ACL of the item from public to the ACL of the category which is a subusergroup of registered users.

The Item inherits the Access Level and Subscription Levels from the Release. The Release inherits the Access Level and Subscription Levels from the Category. In order for this to work you need a BleedingEdge Category and let ARS discover the Releases and Items by itself. If you manually create / edit Releases and/or Items it will not work.

Also keep in mind that if you try to download an Item but either the Item, the Release the Item belongs to or the Category the Release belongs to is set up with an Access Level OR subscription level which doesn't allow you to access it then you will not be able to download the Item.

Finally note that we do use this feature several times a week, uploading dev releases to our site. It works. I did check.

Where do I find this link?

I'm not sure I understand you. You have pretty much answered this question yourself: it's in the update XML file itself. This URL is different for each item and release.

What are Subscription Levels?

Only shown and enabled when you have Akeeba Subscriptions or PayPlans installed. I see that the documentation needs updating, it talks about "AMBRA groups" but this feature was replaced with the Akeeba Subscriptions and PayPlans integration.

But I need to put that link there into that xml file. Hence I need to copy it from somewhere

Let's try this again. Go to Extensions, Akeeba Release System, Update Streams. Next to each update stream there are four links in the Links column. Click on the XML link. This opens the XML update stream generated by Akeeba Release System. You can find the URL in there.

When I put that link in the browser I get the download, but the Joomla updater cant do it. It looks like Akeeba cannot figure out the download ID. I checked and the download ID is correct

No, this is incorrect. The 303 redirection is issued only when you have an Item which a. links to an externally hosted URL or b. is stored on Amazon S3.

In the first case (externally hosted URL) Akeeba Release System puts the externally hosted file's URL in the XML update stream. Example: http://cdn.akeebabackup.com/updates/abcore.xml As you can see the download URL is http://cdn.akeebabackup.com/downloads/akeebabackup/4.2.4/com_akeeba-4.2.4-core.zip, the direct download URL, NOT a link pointing to Akeeba Release System itself.

In the second case (file on Amazon S3) sorry, you can't work around it. Your only option is to use an Amazon CloudFront distribution for the S3 bucket and set up the Item as a Link (not a File), pasting the Amazon CloudFront URL for the file. This is exactly what we do. The cdn.akeebabackup.com subdomain is, in fact, an Amazon CloudFront distribution for the bucket holding our static content on Amazon S3 (updates, free downloads, static media).

As for removing the stability tags, it is irrelevant to the 303 redirection. Completely irrelevant. Most likely while you were playing with it you ended up copying the update XML generated by Akeeba Release System which already contains the direct link to the externally hosted download, fixing your issue. You incidentally removed the stability tags as well but that was an irrelevant change.

PS: Do note that we've been using ARS to host updates to our components ever since Joomla! 1.6. We started actively using them instead of Live Update for all of our software since Joomla! 3.3 last year. We've had no problems with our updates and we're talking about millions (yep, millions, plural) of updates in this time frame :)

Are you sure you've set up your update stream correctly and assigned the update stream to each download item? If you don't tell ARS that this and that item belong to update stream X then of course you get an empty update stream.

I think that instead of a BleedingEdge category you should really use a normal category and something like Akeeba Release Maker. It's a very convenient release automation tool. You can even integrate it with Phing, Ant or other build automation software to automate your software deployment. To give you an idea of what I mean, the latest release of Akeeba Backup required only the following command line:

git tag 4.2.4 && \
cd build && \
phing all release docsdeploy -Dversion=4.2.4 && \
git push --tags

My Phing build scripts built the releases, uploaded them to Amazon S3 and my site (over SFTP), created the Release and Items, published them, uploaded the XML update stream to S3 and then uploaded the new documentation version to my site over SFTP. It took about 5 minutes from start to finish during which time I just got up and myself a fresh cup of coffee.

You should really think about release automation. It's not just the time it saves you, it's the repeatability. Before automation I had an A5 page checklist I'd print before each release and spend then next 30 minutes following it and double checking each step. It was horrendous and you can bet I made mistakes. After I automated the release I only have to get up from my desk for 5 minutes while the build is in progress and I can be sure that every step of the process is followed accurately and absolutely. No more release errors!

Take a look at https://github.com/akeeba/buildfiles especially the phing and phingext directories. I think you'll like it after all :)

As for why use the CLI instead of a GUI, it boils down to this: I started using computer in 1992. Back then it was MS-DOS or go home. The cool thing you learn when having to spend hours and hours in front of a terminal is that CLI can be automated. It can be automated to the kazoo. You can have a script for everything. The GUI is merely a Graphical User Interface to the automation you achieve with CLI tools.

So right now I'm using the best of both worlds. I've created all my automation with PHP, Git and Phing. I am usually interfacing them through Tower (for Git) and phpStorm (for Phing builds). I only drop to the CLI on release day because I trust that my command line, the only item in my checklist, will work every single time in the same, expected, tested and proven way whereas the correctness of me using the GUI depends on me not screwing up what I click. I don't trust humans for accuracy, not even me. Human brains are designed to be creative, not accurate. This is why we make great programmers and designers but genuinely suck at carrying out a release without botching something as simple as clicking the right option from a list of three possibilities ;)