How best organize a project, versions?

[Ronald S. Cook]

We are about to undertake a an app dev project at our company. The overall
project has a name (let's say "DBD - Digital Business Design"). Within the
scope of the project will be several applications, some interdependent, some
stand-alone).

How should we document and version things?

Should it be DBD 1.0 which consists of App1 1.0, App2 1.0, App3 1.0? If we
have just a "DBD 1.0 Vision/Scope" document (covering the apps within it),
that would work I suppose. But then what about after its all deployed?
What if a change is warranted in App2 1.1. If that was scoped and developed
separately than DBD 1.0 is now obsolete.

Just looking for best practices.

Thanks,
Ron

[gerhard.stephan]

Hi Ronald,

as a project leader and developer I know those problems very well.
First I think their will be no right or wrong, but for my view I think
I found a proper way to go.

My folder structure looks like:

\{Your project name}
\Build -Contains build scripts
\Source -Contains source code
\v1.x -Contains code for version 1.0 to 1.99
\{Apps}
\v2.x -Contains code for version 2.0 to 2.99
\{Apps}
\Distribute -Contains stable distributions as ZIP and MSI
package
\Release {Release Number} -Every distributed Release has it's
own folder
\Documentation -Contains documentation documents
\{Sub folder for documentation}
\Test -Contains a current nightly build test run

The reasony why I bundle more versions to 1.x and 2.x is that major
changes (like you expect from a major release change), requires big
changes within the code base. That's why I think it's better to get rid
of the old v1.x stuff and begin with a clear fresh file structure 2.x.

On the other hand, building a new folder structure for every small
release or patch doesn't make any sense, because it's much work and
storage to copy always a complete folder structure. Therefore I
strongly recommend to use a source code management system like
SubVersion or CVS. Those tools allow you to manage smaller release
changes and set marker tags to pin your source for a specific version.

Hope I could help you
Cheers

Gerhard

BTW: If you need a good O/R Mapping Tool look at :
http://www.objectmapper.net or http://blog.objectmapper.net

Ronald S. Cook schrieb:

We are about to undertake a an app dev project at our company. The overall
project has a name (let's say "DBD - Digital Business Design"). Within the
scope of the project will be several applications, some interdependent, some
stand-alone).

How should we document and version things?

Should it be DBD 1.0 which consists of App1 1.0, App2 1.0, App3 1.0? If we
have just a "DBD 1.0 Vision/Scope" document (covering the apps within it),
that would work I suppose. But then what about after its all deployed?
What if a change is warranted in App2 1.1. If that was scoped and developed
separately than DBD 1.0 is now obsolete.

Just looking for best practices.

Thanks,
Ron