Skip to main content
Software Engineering

Return to Answer

removed extraneous text
Source Link
edit approved Aug 18, 2020 at 16:52
Rob Bednark
edit approved Aug 18, 2020 at 16:52
Rob Bednark
  • 117
  • 4

I find myself rarely agreeing completely with Jeff Atwood, but I tend to follow hisJeff Atwood's opinion of the .NET convention of version numbering.

(Major version).(Minor version).(Revision number).(Build number)

More often than not, for personal projects, I find this to be overkill. The few times where I have worked on substantial projects like search engines in C# I've stuck to this convention and have been able to use it as an internal tracker effectively.

I find myself rarely agreeing completely with Jeff Atwood, but I tend to follow his opinion of the .NET convention of version numbering.

(Major version).(Minor version).(Revision number).(Build number)

More often than not, for personal projects, I find this to be overkill. The few times where I have worked on substantial projects like search engines in C# I've stuck to this convention and have been able to use it as an internal tracker effectively.

I tend to follow Jeff Atwood's opinion of the .NET convention of version numbering.

(Major version).(Minor version).(Revision number).(Build number)

More often than not, for personal projects, I find this to be overkill. The few times where I have worked on substantial projects like search engines in C# I've stuck to this convention and have been able to use it as an internal tracker effectively.

Source Link
Mike B
Mike B
  • 1.3k
  • 10
  • 11

I find myself rarely agreeing completely with Jeff Atwood, but I tend to follow his opinion of the .NET convention of version numbering.

(Major version).(Minor version).(Revision number).(Build number)

More often than not, for personal projects, I find this to be overkill. The few times where I have worked on substantial projects like search engines in C# I've stuck to this convention and have been able to use it as an internal tracker effectively.