Versioning different flavors built from shared source

Question

I need advice on how to version builds based on shared and separate codes at the same time. I have a gradle project with multiple flavors. Large part of the code is shared. Some parts are flavor specific. Depending on which flavor I target, the corresponding code gets included.

I currently use semantic versioning. v1.2.0 was released before introducing any flavors. Now, if I make a change to flavor A specific code, I could release it as 1.2.1. But I make a change to the shared code next time around, should all flavors be released as 1.2.2? This will cause some flavors to jump versions in the future.

On the other hand, if I use separate version numbers for each flavor, it will be difficult to track common changes just by versions. Each flavor will have its own fix version for a specific bug for example.

Alternatively, I could maintain a single internal version for the common code, and separate versions for each flavor that can go out of sync. Again, this would make it a bit cumbersome to keep track of common features and bug fixes.

What do you think is the best approach?

Answer 1

It seems to me that you have shared library code that forms part of 1 or more products (flavors). Personally, would version the library code independently. For example, if your library code consists of 3 modules, each could be versioned independently following semantic versioning.

Each product could then declare which library code it uses and the version it's designed to work with. Each product would then also have it's own semantic version.

In this way you can develop each module independently whilst supporting different release cycles of the products.

Answer 2

I'll start out by saying that it's OK to skip versions. Microsoft did it when jumping from Windows 8 to Windows 10, it happened with Apple OS X. These days it's not uncommon to have jumps in numbers between releases.

I say that to say this: if you don't intend on changing how you build your library, just allow for jumps in versions and it's OK.

I would recommend splitting your shared code from your flavored code. You see examples of this in several libraries where you add support for different frameworks (flavors) in layers. For example:

• Fantastico.Amazelib.Core -- all the common stuff
• Fantastico.Amazelib.NInject -- add support for NInject framework
• Fantastico.Amazelib.MicrosftDI -- add support for MS dependency injection

Etc. You should get the drift. With this arrangement, your core library might not change much, or it may change more often than the different flavors. That doesn't matter. You can version them independently and your users can take advantage of the upgrades when they choose.

Answer 3

A typical version is W.X.Y.Z

W = Major X = Minor Y = Flavor Z = Build

Maintain a trunk or master build which flavors merge into and common changes merge out to flavor versions.

Example:

Master/Trunk

Version

1.0.0.0, first build 1.0.0.1, second build 1.0.0.2

Trunk Flavor 1

1.0.1.0, first build 1.0.1.1. etc

Trunk Flavor 2

1.0.2.0, first build 1.0.2.1 etc.

This will allow you to identify what master/trunk version a flavor originated from.

If you needed to bump the master you would make it:

1.1.0.0, then all flavors that can from that master would be:

1.1.1.0 1.1.2.0 etc.

If you merge trunk into any flavor the next build number represents the version that includes the trunk changes and vice versa back to trunk. Major/Minor/Flavor versions don't change on merges, just the build incremented as the merge is treated just like another other code change.