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
|
