Tag Info

Hot answers tagged

79

Instead of having two code version with a common base you should design your application in a way to make those premium features plug-able and driven by configuration rather than different code bases. If you are afraid to ship those premium features (disabled by configuration) with the basic version you can still remove that code in a final build/packaging ...


37

I strongly recommend not using branches for this purpose. In general, you should consider branches for things that will be (or might be) merged back together again later (or for release branches, where you eventually stop development of one of the branches). In your case, you will never merge your "basic" and "premium" versions together, and they will both ...


9

We are using 2 separate projects, the Basic one and the Premium one that depends on Basic project. Do not use braches, they are usually used for features.


6

Alice should handle this situation by rejecting the pull requests which also change the version number (both of them). Collaborators who are not the maintainer should not be changing the version number - that is the job of the project maintainer.


5

If Alice is the maintainer of the project, then Alice and Alice alone should be the one that increments the version. Increasing the version number means a release, and Alice is the one to decide when to release - not Bob and Carol. Whatever code Bob and Carol contribute, you can be 99.99% certain it'll still work even if they don't increment the version ...


5

You can create separate Git repositories for each library, publish them, then use Git submodules to link them to the main repository. git submodule add submodule1_url directory1 git submodule add submodule2_url directory2 git commit -m "add submodules" Working with submodules is a little more complex. After cloning the repo, you need to clone the ...


2

My place uses tags for releases and hotfixes, where hotfixes are a letter subset of the current release. Ie release/1.0.1 hotfix/1.0.1a hotfix/1.0.1b release/1.0.2 and so on. It helps keep merge points grouped together by a common value so you can be sure what was put in where. Certainly, it creates overhead because you're reverting multiple commits, ...


2

It appears to be fairly common, yes. Have a look at the Wikipedia article on software versioning. Quote below is from that page: Designating development stage Some schemes use a zero in the first sequence to designate alpha or beta status for releases that are not stable enough for general or practical deployment and are intended for testing or ...


2

The important thing here is to have a consistent workflow which can be easily followed by both newbies and veterans in your organizations. Decide on a process which meets your requirements and ensure that the workflow makes sense for both trivial and more complex changes. That said, there are a few standard workflows out there. Here's a few of them: ...


2

While most current answers are in favour of conditional compilation instead of branches, there is one scenario where there is a clear benefit to using branches: if you (now or later) decide to make the source code of the basic version available, including all the version history but excluding all the premium features, then you can do so with the branches ...


2

Restructuring everything completely during the migration will probably mean you introduce a high risk of breaking the existing build processes. I would think twice before going that route. The much better alternative is to make 1:1 migration first, and change the structure afterwards, step by step. Any modern versioning system will record the structural ...


2

It sounds like you've got some flexibility in how you migrate your codebase. One option would be to make a "clean break" where you set up the new system according to the newer best practices that you want to adhere to. In that case, you can just export everything you want from the old system and import into the new based on whatever structure makes sense. ...


1

I will not call it a "pattern" per se. It's only a convention that has stuck over the years with web developers. There is no benefit from naming a folder something else other than app, and vice versa. I can only think back to Rails when thinking of the start of this convention. I think it was a means to separate the app's source code from the cource code ...


1

Not as such; There is not one standard versioning scheme. As such, each project tends to choose a versioning scheme that fits their development/release model (and this is perfectly fine, as long as the versioning scheme is known, consistent and respected by developers). Here are some version examples I've used over the years: Linux/OSS - style version ...



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