Tortoise SVN and online repositories

[kyrathaba]

I've been using Tortoise SVN for about a month now to backup my work on a C# project.  Love it!  Anyone have any knowledge about how to do revision numbers?  I confess I really don't understand revision numbers.  I've been occasionally updating my "version" as I add considerably more features.  Now I'm at v1.2, but don't have any rational why it's "1.2" and not 0.99 or 1.3.  Any help?

Also, anyone have any experience creating patches with Tortoise SVN?

[Deozaan]

Revision numbers or software versions?

AFAIK, revision numbers are automatically assigned by each commit to the repository.

As for software "versioning," it's largely up to you how to do it. Quite often I see the format as something similar to major.minor.build.revision.

I personally follow a format something like this:

major.year.month.day[.minor/build/whatever I feel like at the time]

Although I haven't been completely consistent with that system. In one case I've actually done major.build.year.month.day. You can click the little icons in my signature for more examples, if you feel so inclined.

I just like the idea of the date being in the version so you can easily tell at a glance how long it's been since the last update. But it does lack the simplicity of being able to say "Upgrade from 1.2 to 1.3 now!" I'd have to say "Upgrade from 1.2010.10.01 to 1.2010.10.05 now!"

EDIT: Spelling and clarification, etc.

[kyrathaba]

Thanks, Deozaan.

Question: how do you identify what a "major" versus "minor" revision is?

[Renegade]

Thanks, Deozaan.

Question: how do you identify what a "major" versus "minor" revision is?

-kyrathaba (October 06, 2010, 07:38 PM)

Functionality. It's really very subjective though. In the Unix/server world, versions tend to go up slower than in the consumer-level end-user PC software world.

[Deozaan]

Question: how do you identify what a "major" versus "minor" revision is?

-kyrathaba (October 06, 2010, 07:38 PM)

Functionality. It's really very subjective though. In the Unix/server world, versions tend to go up slower than in the consumer-level end-user PC software world.

-Renegade (October 06, 2010, 07:45 PM)

Exactly. Whatever you think is a minor change, raise the minor version number. If you think it's kind of a big change but not a major change, go up a few minor version numbers (e.g. 1.0 to 1.5). And of course if you think you've made some major changes then go up a major version number.

That's just my opinion though. I don't know much about it since I don't release much software. Big software companies or actually just about any other person most likely do something else.

Take a look at mouser's version numbers.

[barney]

Been a while, but when I was in the corporate atmosphere, I was give very strict - yeah, right! - guidelines on this topic.

The sequence required was version.subversion.revision.build, where

• build was incremented any time the proggy was recompiled, usually for things like spelling corrections in error messages and such
• revision was incremented any time, still using the error msg example, the error procedure was altered, e.g., the error trigger was adjusted
• subversion was incremented when a significant change was made, e.g., a completely new error-handling routine, a different UI presentation
• version was incremented whenever there was a major change, i.e., a totally new interface, a new approach to program application, and the like

However, I don't recall the folk who provided me with that dictum following it very closely  .

As mentioned, it's pretty much a case of personal preference.  Methinks the biggest reason for version.subversion.revision.build was to keep track of changes in a multi-developer/team environment, as well as for the bean counters to keep track and know when to charge for an upgrade or raise the price altogether  .

[kyrathaba]

Hehe, thanks barney   That's about what I suspected.  Since I'm a one-man software-team, and since the current app I'm working on is liable to be used only by a very limited number of people, I won't worry too much.  Been working on it since August, and it's grown (in total, counting all modules) to over 4,000 lines of code.  I've gone from 1.0 to 1.3, so far...