Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Versioning of artifacts in main and feature branches
Are these branches setup to do feature branches in the git way, or are they just different release streams?

To deal with release streams, what Eclipse projects typically do is update the version between different branches.
For example the version of a plugin in the juno branch would be 3.1.0, and its version in the kepler branch would be 3.1.100.

This gap of 100 is left intentionally so that users from juno can eventually be updated to kepler.

Pascal

On 06/02/2014 7:45 AM, Ken Lee wrote:

Hi all,

 

We are currently facing some problems in the Scout project regarding versioning of our bundles / feature located in our develop branch (=our main branch) and feature branches.

The current version of the bundles and features is 3.10.0 in the develop as well as in the feature branch.

There’s a continuous build for the develop branch using Maven / Tycho . Artifacts resulting from the CI build are deployed automatically to our Maven repository.

Since some other project teams rely on the changes made in the feature branch, we had to set up another CI build that also deploys the build artifacts to the same Maven repository.

 

We use target files to define our target platform. In the development target file we declare all feature versions with “0.0.0” so that the latest SNAPSHOT build is fetched.

However, since we have builds from two branches (could be even more in the future) with the same bundles and feature IDs along with the same version number, the latest deployed SNAPSHOT artifact is fetched from the Maven repository which could either be the one from the develop or from the feature branch. This behavior is certainly not desired.

 

In Maven we could define the artifacts version of the feature branch like “FeatureX-3.10.0-SNAPSHOT”. Due to the limitation of OSGI versioning where only Integers are allowed for Major.Minor.Service numbers, this approach is not possible.

 

So far we’ve been thinking of some solutions:

·         Change the groupId of the artifacts in the feature branch. In this case it’s guaranteed that the right dependencies are resolved.

·         Increase Service number in the develop branch, whenever a feature branch needs a CI build. The feature branch will get the previous version of the develop branch.

·         Feature branches will get a lower version number, e.g. 0.0.1. In this case fetching artifacts with version “0.0.0” would result in getting the one from the develop branch.

 

However, none of these solutions are satisfiable with respect to maintenance and merging of the feature branch into the develop branch.

 

Are there any other projects encountering the same problem? What have you done to solve it?

 

Cheers,

 

Ken



_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top