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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
