Release 2.0 instead of 1.9 (Thoughts?)

[MikeAlhayek]

We are planning to Release 1.9. However it contains so much breaking changes so for that reason I think we should release 2.0 instead of 1.9. 1.8 will then be the last release for 1.8 and we'll continue with 2.1 release after the next release.

I am adding this issue so we can discuss and see if there are any objections. If we do this, here are something we should also do

• In our code change all 1.9 to 2.0 including release notes so start producing 2.0 previews every night
• We can get rid of any code that is marked obsolete before releasing 1.8 because now we can since we are releasing a major version
• All issues that are currently with tagged with 1.x should be changed to 2.x.
• All issues that are currently with tagged with 1.9 should be changed to 2.0.
• Re-title the discussion What do you like to see in OrchardCore 3.0? #15530 to (What do you like to see in OrchardCore 3.0?) as these ideas would be reviewed when we ready for 3.0.

Important

We should tackle all open issue with 1.9 so we can resolve them ASAP and very soon release 2.0

Moving forward, we will not release any breaking change in a patch or minor versions which will stabilize OC and simplify the dependencies for library creators. For more discussion about this can be found here

Your Opinion Matter

If you like this please thumbs up or down this plan.

@Piedone @sebastienros @hishamco @Skrypt @BenedekFarkas @agriffard @rjpowers10 @ns8482e @deanmarcussen @lampersky @sarahelsaig @MichaelPetrinolis @MikeKry @giannik @hyzx86 @SzymonSel @gvkries

Feel free to ping other to provide their input here.

[hishamco]

Can we move it into a discussion instead?

[hishamco]

If we want to release 2.0 next, IMHO we need to take a deep breath and look at the entire source

• Remove obsolete methods
• Make the projects, and types consistent as much as we can
• This is a good point to break anything if it will make the source better because after that we don't have a chance until the next major release
• Use SemVer seriously, there is no need to break in minor releases even if there's a workaround, personally, I suffered a lot especially if you manage libraries that rely on OC, I know I'm not the only one :)
• Testing, testing and testing
• UI refreshment if it's possible
• Reduce the amount of adding new features and modules, and focus on quality & stability as @Piedone mentioned in another issue
• Please let us not hurry this time to release the next version, as we see 1.8.0 introduces many patches, so don't let .NET 9.0 accelerate the process, .NET is the LTS version
• Let us have a look at 1.2k issues seriously, many of them have not been reviewed which introduces bad feedback, as a core team we should respond in good time but not make them open for years :(

[MikeAlhayek]

@hishamco I submitted it as an issue so we can triage it and discuss it in the next meeting.

Everything you listed is great, but we don't have time to jam all that in 2.0. We should be releasing the new version soonish. At this point, we need to fix last known bugs that are blocking the next release and release it. Releasing 2.0 instead of 1.9 will give us solid plan for next releases where we stick to a plan where we don't introduce any breaking change in a minor release.

We can safely remove obsolete methods in 2.0 and the other items you listed can be part of 3.0 "if possible" or later in 4.0.

The plan is to release a new major annually "is possible".

[hishamco]

We should be releasing the new version soonish

As usual :)

Believe it or not, if we don't take a deep breath the code base will still be inconsistent, and no way to introduce a breaking change until the next major release

So If we need to release 2.0 let us announce it in Orchard Core Harvest, please no one says we will ship it within 1-2 weeks :)

[MikeAlhayek]

@hishamco we have to ship something soon. If not 2.0, it's going to be 1.9.

The fact that 1.9 has lots of breaking changes, 2.0 is the one to ship. 2.0 will be the beginning of stabilizing OC and 3.0 will contain much more cleanup.

[hishamco]

AFAIK, OC 1.0.0 took 3-5 years until was finally shipped, don't expect 3.0 will be within 1 year :)

I suggest that @sebastienros do a proper OC versioning something like ASP.NET Core, or we could release a minor version every 3 or 6 months, and the major will be annual or any period that might make sense. At least the audience knows the release plan. I remember the last few years when anyone asked when you publish a release, no one had an answer :) just we keeping say ASAP

For that, the roadmap in terms of features & releases should be clear, so everyone can know where the OC will go in the future

[agriffard]

There is a famous fable in France written by Jean de La Fontaine : The hare and the tortoise.

The moral is: Slow and steady wins the race.

Just to remind that, even if we awaited the 1.0.0 version during a long time, it was a good move because it prevented us from making the same mistakes that had been made for Orchard 1, i.e. releasing the first versions while knowing there were some important features that were not yet available.

After this, we decided to have a release pace of a new minor version every 3-4 months and we almost managed to keep it, which is good.

In the mean time, we tried to improve the release process (steps, ...) so that some other core contributors can take the lead on the new releases (like some previous ones by @MikeAlhayek or the latest 1.8.3 by @Piedone).

I am also in favor of the suggestion of a major annual release, that would be beneficial but let's keep in mind the main leading points which have to stay the quality and stability of the releases.

Suggestions:

• Aiming for the beginning of the year could be interesting because .NET Framework is updated in November and it would let us some time to test and dependent libraries to be updated.
• We could plan them a bit better by keeping a roadmap more up to date (docs, milestones, ...).

[Piedone]

I agree with the points outlined in the issue. I wouldn't do anything more; i.e., we'll call it 2.0 but we shouldn't do any of the other creative ideas under the 2.0 discussion, but rather, do it almost as if it were the originally envisioned 1.9. There's a lot of testing still needed to do, even after the current 1.9 bugs are fixed (Lombiq/Open-Source-Orchard-Core-Extensions#692 but I'd also update DotNest too, because the random public sites there can bring out a lot of previously undiscovered issues).

Planning the major releases for after a new .NET version is a good idea, as well as more planning. I also pondered the latter, but the challenge is that, well, OC is open-source, and every contribution is something that the given person wants (wants to have in OC or wants to work on), and it seems hard to try to get volunteers to follow a plan. But we can try. Probably also reintroduce the Steering Committee.

[MikeAlhayek]

@hyzx86 can you please relocate these ideas under the #15530 discussion to ensure ideas are not missed when we review that discussion when planning the next major release?

@agriffard and @Piedone sounds like you two support the idea of use releasing 2.0 instead of 1.9. Please thumbs up the original post we can can knows in favor and who is not. @hishamco if you do not like the idea, please thumbs down. This will be helpful during the review on Tuesday so we can decide then.

[hishamco]

I'm not against 2.0 but we need a suitable time before releasing it, many things need to be fixed

[MikeAlhayek]

I'm not against 2.0 but we need a suitable time before releasing it, many things need to be fixed

If you are not against, then we really don't need more work than just fixing the known bugs. You have more time in planning 3.0. I mean there is always more work to be done. But not everything needs to be part of 2.0. We should mainly fix the known bugs and release it. 2.x will contain no breaking changes as any breaking change will be part of 3.0 "a year or so later".

[hishamco]

If the code consistency is not done in 2.0 we need to wait one more year, FYI I closed many PRs (for API consistency) because they introduced breaking changes, if we need to release a major version let us think deeply, no rush again :)

[aaronamm]

Apart from major release, I vote for "Having a look at 1.2k issues seriously, many of them have not been reviewed which introduces bad feedback, as a core team we should respond in good time but not make them open for years ."

[agriffard]

I'd like that more people understand that headless and decoupled modes can also be powerful and suit their needs for other cases than standard cms.

Headless => Call api. Can be used with a Static site generator scenario.

Decoupled => Include OC in your solution and set it up, manage your contents from the admin and extend your own app by using OCHelper (I also have in mind some kind of OC SDK that would be easily plugged-in to your app).

We also started some promising Blazor docs and examples (because if there are 2 things that I love using in my devs these days, these are OC and Blazor).

[MikeAlhayek]

@aaronamm this is a good topic to be added in this discussion #15530

@agriffard this is a good topic to cover during 2024 Conference or making videos about it.

[Piedone]

We really don't need any more breaking changes for the upcoming release, whatever we call it; it's also been in the works for about four months, so we should do a release ASAP, reap the benefits of System.Text.Json and anything else, add a lot of automated QA and quality improvements for the next release (#15800), and then we can have a discussion about further refactoring and possible breaking changes. But not before we have a robust QA in place, and those refactorings should be well warranted with clear benefits, agreed on by multiple people, and in-depth.

Going through the issues is something I've started under #15034, and added improvements to curb the infinite growth of issues somewhat; the PR is waiting for review, but processing the issues will take weeks if not months. However, this isn't a version issue and is not related to v2.0.

Please review this for Blazor docs: #15213 Otherwise, docs is not something we need to wait with for any version, you can update it any time, and Blazor/decoupled/headless are all docs topics.

[MikeAlhayek]

We'll be releasing 2.0 instead of 1.9.

Thank you all!