Are there any guidelines to help determine a major upgrade to a product, ie

a 4.0 to a 5.0 as opposed to a minor upgrade, i.e a 4.1 to a 4.2?



Michael Klotz

Yes, Marketing.



For example, if your competitor is planning to come out with a browser

version 5. Even if there are no major changes in your product- make sure you

release a version 5 so you will be seen as being on par or better.



Another example- Your sales team has an agreement for free upgrades on point

releases but not "major" releases and they need to increase sales for the

quarter. Then you do a full release.



My policy:

Changing the primary version #. EG 4.0 to 5.0 is for significant changes in

functionality, features, code or layout.

Changing the secondary number EG: 5.0 to 5.1 is for less than significant

changes of the same type.

Changing a Tertiary number EG: 5.1 to 5.11 is for bug fixes only.

Anything with a letter attached: 5.11A is a version that isn't considered

"production" code.  This is a test build.



Sometimes producers like the .5 also.. EG: 3.0 to 3.5. This is good if you

made lots of changes but you don't want to make it seem like it's "a whole

new world".. 



Build numbers could also be helpful when developing and testing. No matter

what the version you tell the marketing people or the public there is always

the build number to really track development and bugs with. Most major

software development shops do this. AOL, Microsoft and others have many

"builds" of the same "version" software.





Hal Levy

StarMedia Network, Inc.

Intranet Development Manager 



> -----Original Message-----

> From: Michael Klotz [mailto:klotzm@e...]

> Sent: Tuesday, August 14, 2001 6:21 PM

> To: Application Development

> Subject: [application_development] Versioning

> 

> 

> Are there any guidelines to help determine a major upgrade to 

> a product, ie

> a 4.0 to a 5.0 as opposed to a minor upgrade, i.e a 4.1 to a 4.2?

> 

> Michael Klotz

VB supports Major.Minor.Release and allows an autoincrement setting.  This

increments the Release every time you build an executable.  I use the Major

version for complete rewrites, the minor version goes up if there is a new

window or different functionality, and the release always goes up, getting

reset when either of the other two numbers goes up.



The minor number is therefore the most interesting to me as a debugger -

when I release outside of the development phase I write up that three-number

release which a summary of its new features and fixes.



> -----Original Message-----

> From: Hal Levy [mailto:hal.levy@s...]

> Sent: 15 August 2001 20:53

> To: Application Development

> Subject: [application_development] RE: Versioning

> 

> 

> Yes, Marketing.

> 

> For example, if your competitor is planning to come out with a browser

> version 5. Even if there are no major changes in your 

> product- make sure you

> release a version 5 so you will be seen as being on par or better.

> 

> Another example- Your sales team has an agreement for free 

> upgrades on point

> releases but not "major" releases and they need to increase 

> sales for the

> quarter. Then you do a full release.

> 

> My policy:

> Changing the primary version #. EG 4.0 to 5.0 is for 

> significant changes in

> functionality, features, code or layout.

> Changing the secondary number EG: 5.0 to 5.1 is for less than 

> significant

> changes of the same type.

> Changing a Tertiary number EG: 5.1 to 5.11 is for bug fixes only.

> Anything with a letter attached: 5.11A is a version that 

> isn't considered

> "production" code.  This is a test build.

> 

> Sometimes producers like the .5 also.. EG: 3.0 to 3.5. This 

> is good if you

> made lots of changes but you don't want to make it seem like 

> it's "a whole

> new world".. 

> 

> Build numbers could also be helpful when developing and 

> testing. No matter

> what the version you tell the marketing people or the public 

> there is always

> the build number to really track development and bugs with. Most major

> software development shops do this. AOL, Microsoft and others 

> have many

> "builds" of the same "version" software.

> 

> 

> Hal Levy

> StarMedia Network, Inc.

> Intranet Development Manager 

> 

> > -----Original Message-----

> > From: Michael Klotz [mailto:klotzm@e...]

> > Sent: Tuesday, August 14, 2001 6:21 PM

> > To: Application Development

> > Subject: [application_development] Versioning

> > 

> > 

> > Are there any guidelines to help determine a major upgrade to 

> > a product, ie

> > a 4.0 to a 5.0 as opposed to a minor upgrade, i.e a 4.1 to a 4.2?

> > 

> > Michael Klotz

Thanks,



That helps much.



Michael Klotz



-----Original Message-----

From: Hal Levy [mailto:hal.levy@s...]

Sent: Wednesday, August 15, 2001 2:53 PM

To: Application Development

Subject: [application_development] RE: Versioning





Yes, Marketing.



For example, if your competitor is planning to come out with a browser

version 5. Even if there are no major changes in your product- make sure you

release a version 5 so you will be seen as being on par or better.



Another example- Your sales team has an agreement for free upgrades on point

releases but not "major" releases and they need to increase sales for the

quarter. Then you do a full release.



My policy:

Changing the primary version #. EG 4.0 to 5.0 is for significant changes in

functionality, features, code or layout.

Changing the secondary number EG: 5.0 to 5.1 is for less than significant

changes of the same type.

Changing a Tertiary number EG: 5.1 to 5.11 is for bug fixes only.

Anything with a letter attached: 5.11A is a version that isn't considered

"production" code.  This is a test build.



Sometimes producers like the .5 also.. EG: 3.0 to 3.5. This is good if you

made lots of changes but you don't want to make it seem like it's "a whole

new world"..



Build numbers could also be helpful when developing and testing. No matter

what the version you tell the marketing people or the public there is always

the build number to really track development and bugs with. Most major

software development shops do this. AOL, Microsoft and others have many

"builds" of the same "version" software.





Hal Levy

StarMedia Network, Inc.

Intranet Development Manager



> -----Original Message-----

> From: Michael Klotz [mailto:klotzm@e...]

> Sent: Tuesday, August 14, 2001 6:21 PM

> To: Application Development

> Subject: [application_development] Versioning

>

>

> Are there any guidelines to help determine a major upgrade to

> a product, ie

> a 4.0 to a 5.0 as opposed to a minor upgrade, i.e a 4.1 to a 4.2?

>

> Michael Klotz