Milestone 7.0

[tsahi]

Is your feature request related to a problem? Please describe.
The changes we are making now break API, and require a version bump. As you may have noticed, I created Milestone 7.0, and added three issues to it. We need to define what DAAB 7.0 will include.

Describe the solution you'd like
So far the following issues are included in M7.0:

• In Out Parameter  #14 In Out Parameter
• Replace System.Data.SqlClient with Microsoft.Data.SqlClient #38 Replace System.Data.SqlClient with Microsoft.Data.SqlClient
• Split the block into separate packages for each database #39 Split the block into separate packages for each database

But I'm asking myself, is it enough? is it worth while to the user to upgrade, update configuration and code (mostly using statements, but still), to get these benefits? for example, I think adding #37 Expose TPL methods, either instance or extensions, will provide a great benefit to the user.

I'm also curious about how DAAB works on an ASP.NET Core site or desktop .NET Core application. For the best of my knowledge, there is no web.config file, and instead there are JSON files. can DAAB work with that? we have no testing for that. We may need to create some infrastructure for that in Entlib.Common (didn't look there yet).

Another issue is documentation. There is some on MSDocs, but I believe we should have it on our site, if nothing else, so we can keep it up to date. I would also not be surprised if MS removes it by 2023, when it turns 10 years old. And this is true for API documentation, which we should generate from XML comments (there are tools for that).

@Chavoshi @moein-shafiei @turabek @mjrousos I'll be happy to hear your thoughts.

[tsahi]

And we also need to think how to organize the Git branches, assuming we don't want to merge changes into master before they are complete. Currently there is a branch named Split-the-block-into-separate-packages, but we have several other features for this milestone. I have a PR (#42) for issue #39 waiting to be reviewed and merged into this branch, but maybe we should have a milestone branch from master (perhaps even this branch, renamed), and then we'll branch from master for each feature, then merge to the milestone branch, and when we are done, merge the milestone branch to master. Does that sound reasonable?

[tsahi]

Or we can branch from the milestone branch for every feature intended for the milestone, and merge back to the milestone branch.

[jigarce]

#14

[tsahi]

#47 is also essential, because we need to document the breaking changes in this version.

[tsahi]

Other stuff to do:

• Add a project summary. This will also make the project more discoverable in searches.
• Replace the arcane readme at the repo root with something useful, with a code example demonstrating how DAAB helps the users.
• Enable the new Discussions feature in GitHub, so we can coordinate future development more productively.
• Ideally, create a general information page at GitHub Pages, as I discussed in Create end user documentation #47 .