Code Management: Difference between revisions

← Older edit

Code Management (view source)

Revision as of 19:25, 19 November 2020

16 bytes removed , 3 years ago

m

Misspelling of Windows Millennium

[unchecked revision]

VisualWikitext

Anonymous user

osdev>Hypervis0r

Revision as of 12:37, 29 March 2015 (view source) Columbus (talk \| contribs) m (→‎Version Control Systems: Add link to en.wikipedia.org/wiki/Revision_control) ← Older edit		Latest revision as of 19:25, 19 November 2020 (view source) osdev>Hypervis0r m (Misspelling of Windows Millennium)
(2 intermediate revisions by 2 users not shown)
Line 19: Although this is usually less important than the previous concern, you need to keep the way different versions are numbered consistent. Some number versions sequentially (e.g. ''0.1'', then ''0.2'', then ''0.3''...) while others increment the minor version (e.g. the ''2'' in ''1.2'') number sequentially for small updates and only increment the major version number (the first number in the version) only when they add a major improvement to the projects. Some also add revision and build numbers, which are incremented by some random number every time a change is made to a file, which gives weird version numbers such as ''2.2.11127.56150'', which are hard to remember. Additionally, you may give each release a special name. Projects that use that strategy include Mac OS X (e.g. Leopard, Lion, Mountain Lion...), Android (e.g. Gingerbread, Jelly Bean, Ice Cream Sandwich...), Windows (e.g. ~~Millenim~~Millennium, XP, Vista), and probably others I don't know about. Just pick the one you prefer, or something completely different, or even more simple, such as ''MyOS 1'', then ''MyOS 2'', then ''MyOS 3''... it's your project, after all! [http://semver.org/ "Semantic Versioning"] is an attempt to unify versioning schemes. You probably already use a scheme that is close to this one. Line 59: === Version Control Systems === A [https://en.wikipedia.org/wiki/~~Revision_control\|~~Version_control Version Control system] (VCS) is a program that manages changes to your source files (for OSX users, this is much like Time Machine, but enhanced for source code). Concretely, you perform a ''commit'' operation after each significant change (e.g. after you rewrote your scheduler, or added a new driver, don't commit after each modified line), and the VCS will remember the state of the files before and after the changes. This means that if you change your mind and want to see your code again, then the VCS will be able to give it back. A VCS also enables you to generate ''patches'', which are files that contain only the differences between two versions of a same file. But the main point in using a VCS is that it enables two (or more) persons to work on the same codebase at once without interfering with each other. A VCS also allows you to place your source code on the Internet and have your whole team co-operate using a single server. Many source code hosting websites (such as Google Code ~~and SourceForge~~) support accessing your codebase through a VCS, and using such tools for your code gives you more chances to get people to contribute to your project. [[Category:Organization]]