Move Compact Framework to separate project

[CharliePoole]

This needs to be evaluated as an idea.

Reasons to do it:

• The CF community is small and has diifferent needs.
• We could release on a separate cycle.
• CF is something of a legacy platform.

Arguments against:

• We would have to deal with keeping the separate project in sync - or let them go out of sync.
• It's not clear who would manage the separate project.

[oznetmaster]

And where was the "evaluation" of this idea?

Seems like it was proposed, and then executed without any discussion.

All of the issues raised by @CharliePoole are valid issues, but I do not see any resolution of them anywhere.

Are the CF and non-CF projects going to be kept in sync, or not?

If changes are made to non-CF, who is going to port them to CF, the person making the change, or does that responsibility fall on someone else?

Currently, all changes are automatically validated against both CF and non-CF builds.

[oznetmaster]

Also, what about the documentation? Is it going to be split into two versions as well? If the CF and non-CF projects are not kept in sync, then the documentation will need to be different for each.

[rprouse]

@oznetmaster this issue was opened four months ago and I mentioned in #1589 that we would be moving forward with this right after the release. We have been talking about spinning the CF and SL repositories out to their own repositories since before we released 3.0. We have also talked to you many times in the past about leading that effort for CF.

The intention is that the CF and the SL projects will not be kept in sync. We maintained full history in those repositories, so if someone from either community decides to step up and maintain those repositories, they can git cherry-pick desired fixes from the main repo and move them across.

The reality is that we have only ever had one user (yourself) reporting issues against CF and we have only ever had one SL user. For the 3.4.1 release, the CF and SL packages had 130 downloads compared to over 340,000 for the main framework. That puts the CF and SL user base at less than 0.04% of the NUnit user base. Since both received 130 downloads, I expect those might even be bots.

We are also not abandoning those users, we have just decided that it was time to allow the projects to move in their own direction based on the communities' needs. I expect that the majority of CF users and SL users are in maintenance mode and don't need new features, they just need a stable framework. If that is not the case, then the community is welcome to step up. I realize that your situation is different and I am sorry that it will make your life more difficult, but you have been maintaining your own version of NUnit all along and AFAIK, not even using our releases.

We will also not be splitting the documentation. The plan is that new features will mention the version of the framework that they were released in.

[oznetmaster]

So if I want to add features to the CF build that are not in the non-CF build, that will be ok? I was about to push a PR for the @filename issue for nunitlite. Where would I push it? In my case, probably the CF build. Who will be responsible for reviewing it? Who will then port it to the regular nunitlite build, if at all?

What will happen to the documentation then?

I cannot find a CF repo. Has it not been created yet?

"AFAIK, not even using our releases"??? Not sure what you are saying. My releases are 100% in sync with yours. My CF builds even support the majority of features that are omitted from the normal CF build, like DateTimeOffset, and async/Task, since my CF environment supports them.

[rprouse]

So if I want to add features to the CF build that are not in the non-CF build, that will be ok? I was about to push a PR for the @filename issue for nunitlite. Where would I push it? In my case, probably the CF build. Who will be responsible for reviewing it? Who will then port it to the regular nunitlite build, if at all?

Yes, if they are features that are useful for the entire CF community and work on the majority of CF devices. Reviewing will be the responsibility of whoever steps up to maintain the repository. Back-porting to NUnit will be up to whoever decides that it is needed.

I cannot find a CF repo. Has it not bee created yet?

It hasn't been pushed yet, but will be soon.

"AFAIK, not even using our releases"??? Not sure what you are saying. My releases are 100% in sync with yours. My CF builds even support the majority of features that are omitted from the normal CF build, like DateTimeOffset, and async/Task, since my CF environment supports them.

So you are using your own Creston build of our CF releases, not the releases themselves, correct? Our company has abandoned it's Enterprise CF products because we can no longer sell them because nobody can find CE devices to run them on anymore.

[oznetmaster]

Well, there are tens of thousands of Crestron devices running CE/CF, and it is expanding, not contracting.

However, since the releases need to be adapted for the Crestron CF build, I am the only person who "downloads" that build for this base of machines, so that number would never be seen in your download counts

The same is true of other frameworks like FluentAssertions, NInject, and so on. Each needs to be "adapted", some more, some less, but I have them all running on this base of machines.

[CharliePoole]

@oznetmaster After the future of our CF build had been talked about rather loosely for several years, Rob and I decided it needed to be resolved in a firm way. I created an issue to collect comments back in June. There have been no comments. I recently promoted it to a feature from an idea and assigned it to myself. I'm doing it because, as you know, I'm somewhat attached to CF, legacy or not. Rob is doing the same with Silverlight.

Now that it's a feature, we are dealing with implementation details. I won't absolutely say it's too late to question the decision, but it's pretty late since all of us have known this was coming for a while and no users have spoken against it. I hope you will chip in your ideas about the implementation in advance.

Decisions about implementation that I consider semi-firm:

• The history will be retained in the new repository.
• All conditional code that is not used in CF will be removed, along with the conditional statements.
• There will be no general effort to keep it in sync with the main NUnit framework, but individual features can be ported either way as needed.

Decisions not yet made.

• Whether this will be maintained (bug fixes and enhancements)
• Who will maintain it
• How documentation will be handled (I hadn't thought of that)

I hope you'll participate in this with your ideas and efforts.

If you had something to push, there's no reason not to push it, but I hope you'll do so soon. At this point, it's my responsibility to ensure that what you push makes it into the CF repo when I create it. At some point, once the new repo is established, we will merge changes into master that remove CF from it. It's only then that you would need to decide where to push something, assuming we make the choice of maintaining CF.

[oznetmaster]

Crestron and I have discussed using the unchanged CF release in their products. It could be used as is if it were bundled in the firmware of the system. This is a security issue. Other open source frameworks such as Sqlite, Newtonsoft.Json, and OpenSsl are currently bundled in that way.

If that were done, then there would be thousands of potential/actual users of the unmodified CF release.

However still only one download.

Would that change your feelings on this issue?

[CharliePoole]

I think for me, it's the number of users we are helping directly, whether through downloads or otherwise. You and I discussed in the past having an open source Crestron build as part of NUnit, but that didn't seem feasible for various reasons.

What I would like to hear from you is why it makes any difference, since all these users are getting their software from you anyway. Why is it better for you that CF remain part of the standard framework?

Another thing comes to mind, which I had not thought of before but is triggered by your comment. We are in the process of defining our relationship to commercial software vendors more clearly. Up to now, it has mostly been about Microsoft and JetBrains. Is the build that you are circulating open source? Paid? Given to your clients? I don't want to complicate the issue, but I'd like to know if your work falls under the heading of "commercial software" so that it's properly handled in the draft document I'm creating about our relationship to vendors of such software. Of course, you'll also have a chance to review it and see if it would effect you in any way, which it isn't intended to do.

[rprouse]

How many of those other libraries (FluentAssertions, Ninject, JSON.NET, etc) still maintain and release CF builds? I assume you are maintaining your own custom ports of all of those?

I am also very uncomfortable with features and enhancements to NUnit being driven by a commercial vendor. I realize that you make many contributions as a part of your job and we appreciate your help, but occasionally the direction that you want to take the project in is different because of your very specific needs.

[oznetmaster]

None, as far as I know. I believe all my ports are "custom". mono.cecil has CF conditionals in it, but there is seemingly no CF release supported.

I do not work for Crestron.

All of these ports, including the NUnit one, are open source, and are posted on my github repo as requested by users.

Since I currently maintain about 300 ported open source libraries, I have chosen not to post all of them to github since mainaing the github repos would become a major task all by itself. I post them as requested.

I have, for instance, ported a large number of mono and corefx (now .Net core?) libraries to the CF/Crestron framework.

Features and enhancements to nunit for this environment are driven by me, and the feedback I get from the people using the software, not by Crestron. I am sure that Crestron has little if any input to openssl, sqlite, or newtonsoft.json.

No one asked me for a GUI which supported remote nunit testing on CF. I actually wrote that to make my job easier. Just happened to become a very powerful and useful GUI that has been running with nunit 3 since the beginning.

[oznetmaster]

I had considered posting the Crestron version of nunit on the nunit repo. However, as you indicated, it is for a very specific market. It was (and still is) unclear how to do so.

I am probably going to post it on my github repo soon, but no one has asked for it yet, so I have not bothered. Apparently, everyone is happy with the port of nunit as is.

[oznetmaster]

@CharliePoole The reason why having it as part of the standard nunit framework/nunitlite builds is the ability to maintain sync easily.

Changes are made, and I simply, most of the time (if no Crestron specific areas are affected), sync with the changes. If a Crestron specific area is affected, then I have to do the porting of the change manually. This happens about 20% of the time. The other 80%, it is a straight replacement.

One the CF conditionals are removed from the nunit/nunitlite source, that will no longer be the case, and every "sync" will require manual porting.

[oznetmaster]

@rprouse I agree that many times I propose changes that are driven by the needs of ,my environment.

However, many of these have proven to have global applicability.

There are many features in my Crestron build which I have never proposed to be included in the regular nunit build, and some which I have and which have been rejected. The thread per test and my existing implementation of @filename, for instance.

Mu current implementation of test parameter discovery and validation is one which might have global applicability, but which I am still waiting on a response from you and @CharliePoole about. If it is not appropriate, it will still be in my build.

[oznetmaster]

@rprouse I never mentioned json.net. Not sure where that came from. Not even sure what is is?

[CharliePoole]

Between the release in process and my visiting family, I won't be able to contribute much to this discussion for a few days.

[CharliePoole]

@rprouse As we discussed, I reassigned this to you. I had barely gotten started in a local repo so there is nothing to transfer to you.

[oznetmaster]

Since I had never responded to @CharliePoole question about my involvement in the CF repo, I wanted to make it clear that it, in and of itself, is actually of little use to me.

Since my CF build of NUnit contains most of those pieces that are being removed from the CF repo (such as async support, DateTimeOffset, Task, etc), and will continue to do so, I will need to continue to port from the full nunit repo to my builds. There will be little of unique value in the CF build. I will have to continue to adjust the code as required for the CF/Crestron environment, but the CF related changes will not be available to any but the Crestron users.

If this repo is only being maintained because of a single user (as @CharliePoole indicated), then it is probably should be archived and forgotten.

I am curious as to how many .NET 2.0 downloads there are, and how many known users there are of it. So much of the existing code has been dumbed down to remain 2.0 compatible that it seems that removing that build to its own repo might be of significant value as well?

[CharliePoole]

FYI it's not necessary to re-open an issue in order to comment on it.

Separation of CF into a separate repository is a decision we took a while ago, and is now implemented as a result of this issue.

Whether we are going to maintain it in the future is still undecided. I'm working on some higher priority things right now, but I do plan to get back tot his and start a discussion, probably after polling users about their interest.

[oznetmaster]

It is interesting that after changing my source code to removal all SILVERLIGHT and all NETCF conditionals, I ended up with very few remaining CF specific sections of code (mostly due to generic and AppDomain limitations). This is due to the fact the my CF/Crestron framework supports the vast majority of .NET 4.0 classes. So many things that were conditioned out for NETCF are the same for my environment as for the standard .NET one.

This is why I will continue to sync with the full nunit repo, and will not pay any further attention to the CF one.

[CharliePoole]

That makes sense. Logically, there are two strategies to use in dealing with a limited platform like NetCF: either dumb down the framework or extend the platform. We chose the former, you the latter. What we will need to figure out is how many people really want us to keep maintaining a framework for native CF and whether any of them will be willing to work on it.