We should have XYZ merged before shipping RC2
Examples:
Let's create comments with one-liners and have people use +1 -1 icons on each comment.
+1 means WE NEED THIS IN RC2
-1 means IT CAN WAIT FOR 1.0
Autoroute Container routes
I think this should go before "Responsive" to save time & efforts
GDPR
Liquid DictionaryAttributePrefix #5099
Recipe idempotency #5487
AutoSetup #4567
Shells updates #5551 (block me to progress on making other services distributed step by step)
Redis services #5815 (required for distributed cache)
Swagger :) https://github.com/OrchardCMS/OrchardCore/pull/4139 +1
And what @jtkech said +1
Here is what I'd see would be important to say that OC is production ready, which would mean that people that doesn't know how to code could start using these for 1.0 (final). RC2 could include them, because it needs to be tested, but with tasks to finish them for 1.0.
I'm not including CORS because it can be configured still and it's not a show stopper.
updated 03/04/2020
LetsEncrypt +1
+++ Recipe idempotency #5487
+++AutoSetup #4567
LetsEncrypt +1
Spa sample +1
Does anyone want to ship an RC2, or should we just focus on Orchard Core 28 already ;)
Well I switched to the latest builds nuget provider so it doesn't matter to me anymore but I still think it is a good idea to do RC2
See this is what I thought 馃槃 ... people are switching to latest myget dev packages simply.
So the only thing we need is to finish what we have as P0 to P3 in the current 1.0 milestone and make it RC2. But then, what are we testing in RC2?
Don't introduce any new feature for now and fix issues in the current implementation for RC2 to make sure that everything is more stable. Then, between RC2 and 1.0 we can introduce new features to be tested.
If you do a RC2 then the biggest benefit is that it relieves pressure to do release version 1.0
+1 for RC2 Good to have the active pr's for features which are ready merged. but not essential, or worth delaying an RC2 for IMHO
What is essential is a more up to date, stable, version that is available on NuGet, for people running sites in production, that can't be having to deal with package upgrades everytime they need to go back and do some work on a running site.
Plus all the other reasons @Piedone already mentioned
Could we have monthly builds ? A bit more stable than the myget but still "bleeding edge" ?
RC2 + for
Oh no, we're again feature creeping. RC2 doesn't need anything, let's ship dev.
MyGet is not an option since releases roll out. This is the main technical issue why you can't just point people to MyGet. The second is if you're not closely involved with Orchard's development you can't decide which nightly build version to use (thus even if releases wouldn't roll out it still would only be, well, a nightly build, unusable for the general public). Having an RC2 out finally solves this.
I ended up forking the OC repo and merging dev to it every now and then. This fork pushes to an internal nuget feed. This allows us to update often without having to use the * version (which broke a couple times). If we had a monthly release on myget, it would be a bit easier, since myget stores up to 10 releases (10 months).
I tend to agree with @Piedone that to me a main reason for an RC2 would be that the current official nuget release uses an unsupported version of dotnetcore.
If we're gonna add 9million features for an rc2 then we might as well wait for a 1.0 :
Of course we should fix anything we know is urgent/security related etc before the rc2 but that's it for the most part.
A couple more things on why get releases out quickly if there is any new argument needed:
If you check out the upper right corner there is something like this:

I'm just watching releases, which is the minimum to show up in the number here. This means that if we roll out a release, 377 people (let's subtract everyday contributors and else, so let's say, 300) will jump on it more or less immediately. This many people will start using the new version, give feedback, contribute with bug reports, and yes, also fix bugs and add features (having a bug in your shiny new Orchard website is a great incentive to fix it, or add a feature that's lacking in a way that's glaringly obvious to you). There are 300 people completely starved for a release since September.
But wait, there's one more thingie there:

Almost 4000 stars! People abso-fracking-lutely love Orchard. What if we roll out a release, or even releases more or less periodically? There will be even more people who'll love Orchard! OK, but what if we roll out a release that is not perfect and we make a couple of people out of these 4000 sad? We can roll out another release later to fix some of those bugs and win them back, possibly by asking them, or the 300 very enthusiastic ones to fix them!
Isn't it amazing? :) It looks like a huge crowd waiting for something to happen!
BTW if the administrative and housekeeping steps needed to publish a release are in any way prohibitive at the moment for the person doing that (who is Sebastien I'd assume) then after getting some overview on what needs to be done I can do it, as well as document the steps for future reference.
Most helpful comment
A couple more things on why get releases out quickly if there is any new argument needed:
If you check out the upper right corner there is something like this:

I'm just watching releases, which is the minimum to show up in the number here. This means that if we roll out a release, 377 people (let's subtract everyday contributors and else, so let's say, 300) will jump on it more or less immediately. This many people will start using the new version, give feedback, contribute with bug reports, and yes, also fix bugs and add features (having a bug in your shiny new Orchard website is a great incentive to fix it, or add a feature that's lacking in a way that's glaringly obvious to you). There are 300 people completely starved for a release since September.
But wait, there's one more thingie there:

Almost 4000 stars! People abso-fracking-lutely love Orchard. What if we roll out a release, or even releases more or less periodically? There will be even more people who'll love Orchard! OK, but what if we roll out a release that is not perfect and we make a couple of people out of these 4000 sad? We can roll out another release later to fix some of those bugs and win them back, possibly by asking them, or the 300 very enthusiastic ones to fix them!
Isn't it amazing? :) It looks like a huge crowd waiting for something to happen!