StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>In general, I recommend having projects remain separate as much as makes sense (your second option). This will generally promote reuse. (If I only want Dependency2, I don't need to bring an entire other project in order to get to it.)</p> <p>However, you have to be smart about what your dependencies are really going to be doing. For example, if Dependency2 is <em>only</em> going to be a dependency for Project1, then it should probably just exist within Project1's source structure. (Note: I do not mean have separate branches and tags for the Dependency - I mean have it be in a different package, or another subproject within Project1.)</p> <p>If you want to make a project a reusable library within your organization, then have it as a separate project completely so you don't introduce unnecessary co-dependencies. And, I would encourage your development team not to check out a dependency and work alongside that. Instead, build the dependencies and use them as a binary library. This way, whoever checks out a Project to work on it will always have the latest library dependency that they need for the application. If an update is needed, then you can worry about checking out the Dependency and building it. (Or, even better, have a location where project teams can release the latest libraries as binary files.)</p> <p><strong>Update on Versioning of Project and Dependencies</strong> If you go with the #2 route, and have separate Project and Dependencies, your versioning actually becomes very simple. Here is an outline of how it might work.</p> <ol> <li>Team A is working on Project1.</li> <li>Team B is working on Dependency1 which Project1 depends on.</li> <li>Whenever Team B finishing their work, they build a release of Dependency1 (a binary - perhaps a DLL, or a library, or something along those lines). They can also tag their project at this time. The binary name may be: Dependency1-v1.0.0</li> <li>Team A takes the binary release of Dependency1-v1.0.0 and includes it in their project. (Typically, binaries are kept in a /lib folder or something like that within the project.)</li> <li>Whenever Team A finishes their work, they can release their project and tag their project as well. </li> </ol> <p>Note that, at no point, does Team A <em>check out</em> the source code from Dependency1 and bring it into their project. This allows development of the two projects to remain separate so that there is autonomy between the development teams. Team A can use the binary for as long or as short as they like. If they want an updated version, they go get the latest release from Team B.</p> <p>This process is not really much different from what you would do if you were using a library from an outside source. You have no control over how they version their library, so you just grab what you need for your project and update when you feel is necessary. You keep the binary within your own project structure so that you can always rely on it.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload