I'm the Author of a small Open Source nuget package (EnumStringValues, if you care: GitHub, nuget)

It's C#, .NET. Written in VS, hosted on GitHub. I've been the only contributor, and it has ~250 downloads. The scope of the package is relatively small, and thus I've done no work on it since completing initial development and releasing it, 2.5 yrs ago.

Yesterday (presumably prompted by 24PullRequests?) I received a PR which makes a couple of useful changes. In amongst those changes, is the change to upgrade the .sln to VS 2015.

I only have VS2013 at home and don't expect to upgrade anytime soon, and I assume (but will check) that this will render me unable to open the project.

Question: Is it considered appropriate to reject this aspect of the PR? As Author and current sole-contributor, is it considered reasonable to say "my ability to open the project is a requirement"?

What if the changes are dependant on the newer version of VS? (i.e. because they are about .NET framework support (.NET Standard 2.0)

What are the etiquette norms here?

  • If you want to ensure that your project builds under various Visual Studio versions, you can perhaps configure an AppVeyor build (free for open source projects). You can then keep using whatever VS version you prefer, but still be certain that it will work under other versions without changes.
    – amon
    Commented Dec 2, 2017 at 12:49
  • IIRC 2015 project format is the first ever csproj that was backward compatible. If it’s just the project format change, it should work fine on your 2013 version. There’s really no reason not to upgrade to 2015 Community yourself though. Changes to the .Net Standard are different though. Those affect your ability to support older versions of Windows/.Net. That said, I find the existing answers to be correct to the general, OOS oriented question.
    – RubberDuck
    Commented Dec 9, 2017 at 23:58
  • Please have a look at my earlier question that kind of includes this very situation, in particular the comments sections. Commented Dec 13, 2018 at 7:50

2 Answers 2


The harsh-reality answer: You are the project maintainer. Contributors may not like it, but technically, you can reject PRs for any prosaic reason.

"My ability to open the project is a requirement" seems like a reasonable requirement to me, but I'd rephrase it so it doesn't focus on you, but on all users and contributors - "EnumStringValues supports VS2013, and changes requiring newer versions of VS or the .net standard will be rejected". If you really want to be polite, you could add something like "this decision may change in future versions, but will hold for the duration of the 2.x releases".

  • 3
    Don't walk around the problem, simply state the concern. Otherwise the next PR may just find a creative solution to a problem you didn't have in the first place.
    – Mast
    Commented Dec 2, 2017 at 9:18

If it's your project, you should make sure it actually works. Whilst you can't check that some proposed change works (and doesn't introduce anything malicious), you should only pull it if you know the author well already and trust them. That's the only thing I'd consider “ethically mandatory” here. If the PR is a risk factor, don't pull it.

That said, I find it generally rather annoying if project maintainers bog their code down with old standards. So first of all I'd just give it a shot: pull that change, but to a separate branch of your repository, not to master. Then try if you can actually work on that branch with your old version of VS; perhaps this actually works, I don't know anything about .sln. If it does work, then just go ahead.

If it does not work, it might still be sensible to try it: check the project out on a machine that has a suitable version installed (perhaps using a CI service like Travis). If you can confirm that the change is valid but you just can't personally work with it anymore, than my advice would be to pull it in the master branch, but do all your own work on a seperate branch legacy/VS2013 that has an extra commit reverting the .sln file to a version you can work with. After every change, you'd than rebase that commit back on top and reset your master branch to incorporate the relevant changes but not the legacy revert. Goes something like this:

$ git checkout master
$ git pull contributor/proposedChanges
$ git log
...   # Look for the SHA1 of the commit that changes the .sln file
...   # Let's pretend it's 1234abc
$ git checkout -b legacy/VS2013  # make new branch and switch to it
$ git revert 1234abc

At this point you should be able to normally work on your legacy branch using VS2013, while the Github repo is officially at the new standard. If you now make some changes on your branch

$ git commit -m $'Some new change of my own'
$ git commit -m $'Some other new change'

then you first need to rebase that work so update the master branch accordingly.

$ git rebase -i HEAD~3

This will give you an editor view like

pick cba4321 Revert update to VS2015
pick 8820444 Some new change of my own
pick ffe5519 Some other new change

Change the order to

pick 8820444 Some new change of my own
pick ffe5519 Some other new change
pick cba4321 Revert update to VS2015

and save&quit the editor.

After that, git log should also display the new order, i.e. the revert comes last.

To publish your changes without the revert, you now just update the master branch accordingly:

$ git checkout master
$ git merge legacy/VS2013^  # penultimate commit on that branch

and then update the online repo

$ git push origin

...and switch back to your own branch for further work

$ git checkout legacy/VS2013

As a broader thing... if updating is such a problem you might want to consider to switch to an entirely different development environment in the future, preferrably something free like Mono.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.