title: Is it acceptable to use a custom versioning scheme in a .Net library to be published in the common NuGet repository?
body: <p>I have came to a somewhat original version numbering scheme for my projects:</p>
  
  <pre><code>Major.Year.Month.Build
  </code></pre>
  
  <p>e.g.</p>
  
  <pre><code>2.2017.3.4
  </code></pre>
  
  <p>Which means this is a fourth build of the second generation (meaning serious breaking changes as compared to the 1.<em>.</em>.* branch, it may be a totally different app for the same task actually, I just don't want to rename it in something like MyApp2) app made in March of 2017.</p>
  
  <p>I would also love to include the month number but 5-part version numbers seem to be unsupported by Visual Studio / .NET Framework or the Win32 version data resource format.</p>
  
  <p>I've never seen anything like this verbose hybrid of classic and date-based versioning (YEAR-RELEASE is somewhat alike but not much) and suspect that's because it may happen to be too inconvenient, counter-intuitive, untidy-looking or something like that for many, the question is whether this is the case and if the problem is serious enough to make this way of versioning actually discouraged strongly by rules of some sort or the informal convention of the community.</p>
  
  <p>Can I use this way of versioning in a library I plan to publish or is there an established convention that I should comply to?</p>