Tag Info

Hot answers tagged

6

You mention that you are looking at using semantic versioning, so lets look at the semantic versioning spec at http://semver.org/: Given a version number MAJOR.MINOR.PATCH, increment the: MAJOR version when you make incompatible API changes, MINOR version when you add functionality in a backwards-compatible manner, and PATCH version when you ...


5

It's because the modifications are legally considered a derivative work, because they build on and depend on the work already done. This protects the original authors against someone adding a popular new feature that builds on their work, but then making that feature closed source. If authors wish to allow closed-source extensions to their software, they ...


4

I'd keep those feature branches (very much like what you describe now), but make sure they are feature branches, not individual developer branches... Developers work on these feature branches, develop and test their feature. Then on top of that, like you say, have an integration branch where all changes get merged, compiled and perhaps get some day-to-day ...


4

There are two things here - the client (in this case Jenkins) and the server (svn or git or something else). As the client, asking every minute can consume a bit of resources - network and disk on the server, not to mention its own internal builds that compete with local resources for checking if anything has been updated. At the server side, having a half ...


3

Probably because the end users are using your files, not your diffs, and licenses are supposed to be distributed along with your software (whether in source or binary or some other form). You don't distribute your software as a series of annotated diffs, do you? There may also be a legal reason, but that's a question for a different website.


2

Maybe you could create a third project on your source control, which contains only the shared libraries. So in short, your other two projects will reference this shared group of source files. This would allow you to have a group of shared libraries which are self contained, and are not stored within the context of another project. This assumes that you ...


2

Yes, update the version number all the time it moves out of your control and into someone else's. the reason is you need ot know what they were working with. When test comes back and says"we found a bug in version 1.0.0", the last thing you want is to say "which version 1.0.0, the one we gave you on Monday or the updated one I gave you on Friday?" Updating ...


2

I think you are confusing licensing and copyright. Each contributor to a shared project without copyright assignment only owns the copyright over their own contributions, in other words copyright over each diff they produce. A contributor would only own the copyright over a whole file if nobody else contributed to that file. As a result, most files have ...


1

I'm not sure the polling resources argument is compelling. It's a relatively efficient operation on most version control systems, especially if you're just checking and not actually downloading the changes yet. Although, a push notification is certainly preferable. Usually it's the building resources that are the limiting factor, depending how frequently ...


1

Wikipedia describes a software bug as "A software bug is an error, flaw, failure, or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways." As an undesired look can be classified as an incorrect result or unintended behaviour of the UI, a change to correct that look would ...


1

With git you can use git submodule. ProductA can have specific commit_ids (which can be a branch) of some submodules (for example ComponentA, ComponentB, SharedComponentC). To add a component to ProductA, from the ProductA directory on your development machine do: C:\projects\ProductA.git\> git submodule add --branch master --name ComponentA ...



Only top voted, non community-wiki answers of a minimum length are eligible