the traditional argument against this is that it would facilitate people using alpha etc on live sites and the alpha code might not be secure

Nothing stops users from running the staging branch on a live site, or starting a new site on a beta release and never updating it since we say we don't support it.

As I've said in the past, there is no technical reason we cannot support non-stable updates beyond how our SQL deltas are managed (changing them after a tagged release of any stability basically screws everyone over).

I think we shoot ourselves in the foot by basically saying "sure, test an upgrade to a beta release" or "test these new features on a development site" with the caveat of "when you're done throw the site away". My company was actively rebuilding our website through the 3.7 release cycle and custom fields filled a feature we needed, so our development site was updated onto the 3.7 beta releases, and we were bitten by the SQL change made between the beta releases (had I not been here to point out the exact change and how to address it they would've probably mothballed that dev site and their work). So I think we need to be a little more giving to those who are willing to work with us in doing QA or testing new release features and ensure they can get back onto the stable release track without excessive pain.

Are you suggesting to advertise non-stable versions to live installations? (I guess not, but still asking.) Providing a beta channel to do upgrades from beta -> RC -> stable would be fine with me. As far as I understand you, you just want us to promise that you can update from a beta to a stable, right?

Are you suggesting to advertise non-stable versions to live installations? (I guess not, but still asking.)

Absolutely not, unless you are subscribed to a beta release channel (which we don't actually have consistently, right now the testing channel we have is pointed to nightly builds for next patch release).

As far as I understand you, you just want us to promise that you can update from a beta to a stable, right?

Correct.

We have the channel - we just need the commitment to ensure that its possible

I support this change with the condition that instead of SQL files, we provide an XML representation of our schema, so that we can compare and fix tables. That would also allow to ship only one db schema file...

Ok, maybe not the condition, but with the proposal to (finally) go down that route...

At least a RC -> Final would make release testing easier.
I would also like to see beta -> Final upgrade paths but that may mean less flexibility as seen in com_fields.

It's not that the com_fields change was bad. Instead of modifying the SQL delta that had already been released, a new delta should've been created with the added change (unless for some reason it was technically infeasible to do so). That would've avoided that specific issue.

instead of SQL files, we provide an XML representation of our schema, so that we can compare and fix tables

That would definitely be nice...

The XML representation would only help with stuff that our db fixer already can handle. It wouldn't help with things where we modify content. Allthought that happens rarely.
It would be nice of course, but it's not a requirement imho. We just need to add a new SQL delta instead of modifying the old one.

I think allowing updates from beta releases should be doable and makes sense.
I probably would still not support it for alpha or nightlies, but that isn't the proposal here anyway.

Is XML the best way? Laravel and others uses PHP migration scripts for this, no I idea if this is better.

I don't know if XML is the best way to go, but an XML instead of our spaghetti-install-sql file would be a lot better to manage. I'm using Netbeans and SQL files are simply random text files for it. There is no way for me to jump to a specific table in a large file. I would guess that with an XML file (or even included in our manifests), we could also do some very fancy verification and testing stuff on PRs.

Mirgration files make life so much easier :-) I like the way laravel is doing it.

Back to the initial question, +1 on the proposal

Anything is better than relying on the fact that we don't have the full SQL schema available in a site after it's installed (because the root SQLs are in the deleted installation directory) and we therefore rely on checking the SQL deltas in com_admin to determine if things are in the right state based on whether certain changes are applied.

I see no harm in supporting updates from betas as users would need to actively enable it. So they should be aware of the consequences. As for the SQL deltas, I have given up on them and implemented the XML approach in my own extensions. Over were the update issues :)

If this was the case I would use betas on all new builds. I try to anyway but it's not always feasible. Downgrading would also be a nice feature if a release takes a long time and my new build is released first. At least you will have got some testing out of me.

Can we sum up that we support the original RFC? I propose the following wording:

4.4 Development releases

All Alpha, Beta and Release Candidate releases (defined in SemVer as "pre-releases") must always be regarded as unsupported. It is entirely possible that these releases may contain serious bugs, security issues, forwards and backwards incompatibilities, entire features that are subsequently withdrawn, and so on. There will be no supported update or migration paths from a development release to any other release. The project will try to provide updates between pre-releases and to a stable release, but without the guarantee that these updates will work in all cases.

Feel free to change the wording, but lets try to come to a solution here.

Text makes sense to me.

Also keep something in mind here. We're working toward the 4.0 release. Once we get that to the beta milestone, we REALLY should be providing best effort to ensure continuous upgrades between tagged releases. I think it actually hurts testing or early adoption of new releases/features if we can't give users a bit of assurance that we'll do our best to ensure they can move a site forward that is working from a tagged beta/RC package, so this is really a statement of "thanks for helping us to test/validate our releases, we promise we won't make it painful for you to get back on the stable track unless some extremely exceptional circumstance arises" (and even then it should be documented in whatever pull request(s) creates said circumstance so that that early adopter/tester group can manually make whatever updates are required).

Is this something that should now be taken to the Production Department for a decision?

Is this something that should now be taken to the Production Department for a decision?

Please a Decision.

I like the idea to support betas and onward, but alphas should not be included.

Closing due to lack of response.

Its on the list for the next production department meeting, stay tuned :-)

Either the meeting happened and the minutes were never published, or the meeting happened and the topic was never discussed, or the meeting never happened and the topic has still never been discussed. Either way, silence speaks volumes.

It is much easier, we discussed it at the meeting but forget to start a voting email. This was done before the meeting this week and till now we are reached a majority in favor of the proposel.

[RFC] Continuous Upgrade Path is accepted.

Now we need to implement the process and change the development strategy document.

So far this has not been implemented. So are we just closing this now to be forever forgotten?

It's supposed to be implemented as of 4.0 Beta as we mentioned in the Alpha 6 blog post:

To make the life of testers easier, we will be more strict in updating the deleted files and modifying the SQL changes. This will allow updates between Beta / RC and Stable.

I really hope it will happen and not be forgotten.

@wilsonge Can you please confirm?

I can confirm. Like ultimately with this it's just a merge policy thing - we have to delete files added and then re-removed from beta -> stable into the deleted files list somehow (that's something that needs modifying in the build script - that needs to be rewritten anyhow due to the way we've reworked composer and npm dependencies) and we have to not modify sql upgrade files similarly - we just need to commit a modification

we have to delete files added and then re-removed from beta -> stable into the deleted files list somehow

The build/deleted_file_check.php script can pick this up, it's ultimately just doing a diff between two commit references (usually tags). You might have to run it from first beta to stable instead of stable to stable (so 3.8.13 to 3.9.0-beta then 3.9.0-beta to 3.9.0 instead of only 3.8.13 to 3.9.0) to pick up these kinds of changes in the beta cycle as I'm pretty sure if you try to diff two references where a file was added and removed between them it won't show up in that list at all (so your starting reference has to be after it was added).

i mean it has to be more i think. it has to be 3.8.13 to 3.9.0-beta then 3.9.0-beta to 3.9.0-beta2 then 3.9.0-beta2 to 3.9.0-rc1 etc as files are added/removed - but probably safer to always do it than risk missing one. but yes