Tag Info

Hot answers tagged

6

When you use git as version control you can. use your full code as trunk. branch of your students version. continue dev on trunk. merge trunk into branch. do new adjustments for changed code in students branch. All changes in the students branch will persist, git will only take new changes from trunk and add those to the branch, You will probably ...


4

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 ...


4

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 ...


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 ...


2

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 only just saw this question, and there is actually a canned solution - from GE-IP of all places. Check out Proficy Change Management. This product does version control from a PLC control systems point of view, rather than a pure version control of files point of view - it works as a layer sitting on top of a VCS (the scary part is that originally this ...


1

The simplest approach is to use a single repository, so unless you like complexity for complexity's sake, then that should be the default choice in the absence of compelling arguments otherwise. Is the client and server development going to be carried out by different organisations? Will there be multiple implementations of the client (or server)? Is the ...


1

It is more common to use source control branching in order to control what features are available within a particular version of the software. That said, applications that offer tiered functionality within the same version level will sometimes use the technique you describe. Usually, you'll see two main uses of the conditional definitions. The fist uses ...


1

Our team uses the Gerrit code review system, where reviews are based on commits, instead of branches. The learning curve of Gerrit is higher than pull requests, but it creates a much cleaner commit history and allows for fine-grained commenting on code. Our local repositories still contain branches, but 95% of our commits end up directly on the 'develop' ...


1

You mentioned that you are familiar with gitflow. I suggest to addopt it for your scenario. You will need to create branches from your development branch to support older versions. These older versions will also need to have their own release/master branches and hotfix branches. You will need to periodically merge your support branches into the newer support ...


1

Version control really is the wrong tool for this. (Of course, you should still be using version control for your code!) You don't have separate but inter-related lines of development for your code. Instead, what you have is two completely different pieces of code. However, those different pieces of code are related in such a way that one can be ...



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