On a slightly separate, but related note... One way of handling differing versions between potentially independently releasable artifacts/modules is to create a Maven BOM file.
geode-examples are one thing, but when Geode becomes truly modular (in a sense that naturally bounded modules... Core, Querying/Indexing, Persistence, Client/Server, Native Client, WAN, etc) with independently releasable components having separate artifacts and release schedules, then using a Maven BOM with a "symbolic" version name to coordinate the curated, harmonized and complete set of versions is the easiest, most convenient and familiar way to handle this. These "symbolic" versions could then be used in JIRA as well, which might actually have more meaning in the sense that it forms unity with other seemingly unrelated "by version number" components. A few examples... [1] https://github.com/spring-projects/spring-data-build/ blob/master/bom/pom.xml [2] https://github.com/spring-io/platform/blob/master/platform-bom/pom.xml [3] https://github.com/reactor/reactor Food for thought... -j On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker <aba...@pivotal.io> wrote: > Currently our JIRA versions look like this: > > 1.0.0-incubating.M1 > 1.0.0-incubating.M2 > 1.0.0-incubating.M3 > 1.1.0 > > That works great for the geode repo. However, what about the > geode-examples repo? I would like to set a ‘Fix version’ that matches the > version in [1]. Since the repos can release independently of each other, I > think we need a way to completely disambiguate versions like > ‘geode-examples-0.1’. We could also ask for a JIRA project for each repo. > Thoughts? > > More stuff: > > - GEODE-2318 didn’t get updated with commit logs from geode-examples. > Anyone know how to fix this? > - Travis-CI is now running on geode-examples. If you notice problems with > PR’s or email notifications let me know. > > Anthony > > [1] https://github.com/apache/geode-examples/blob/develop/ > gradle.properties#L17 > > -- -John john.blum10101 (skype)
