+1 to all the (excellent) points Udo made... Also to address this concern...
> were not mentioning the versioning hell one does go through to get all projects on the same version This is exactly the reason for having a Maven BOM file. And, is exactly the reason the Spring IO Platform (http://platform.spring.io/platform/) exists, give the vast Spring ecosystem and significant number of 3rd party dependencies. I want to emphasize one more time... it is not logical to hold up individual parts of Geode just for other parts to catch up, feature/crucial bug-fix wise, what-have-you (or worse, superficially bump a version number because Native Client, for example, had a release). It is also not logic for a new client to some in as version 1.1.0 or later. This is the same monolithic, glacial pace that plagued GemFire into long release cycles of the past with very slow time-to-improvements. 1 thing is for certain, you cannot move that many complex pieces at a predictable and reliably quick pace for long. On Thu, Jan 19, 2017 at 1:13 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote: > I don't know if I necessarily agree with this "lock-step" simplicity, > every repo/project has the same version. That would become WAY too hard to > vote on all the time... > > I can see scenarios where geode-server might add functionality and which > clients don't need. Yes, we could version all the clients to be the same > version as the server code, but then it is really a "superficial" version. > > When we get the client protocols sorted and stabilized, I don't see a real > reason to keep everybody on the same version. I think all clients should > have the freedom to be on a different versioning strategy. If we were to > take the "native" client as an example, when we get a pure .Net client > impl, does it mean we have now bump all related projects (incl. server) to > the next major? Because in reality a pure .Net impl should be a major > version. > > In addition to that, what about any new client implementations, do we > start them on 1.0 or whatever the current versioning strategy is currently > being used by the rest of the clients? > > I think documenting (maybe even tracking) what versions of clients will > work with a version of the server is acceptable. > > As John pointed out Spring is a PRIME example of this... The core is due > to be on 5 soon, but you don't see any of the related projects keep in > lock-stead with that. Data, Security, Web Services, Cloud,.... they are all > on different versions, but somehow play with one another.... (were not > mentioning the versioning hell one does go through to get all projects on > the same version).... > > I think that we will soon find that even IF we decide to have all the > projects/repos be on the same version, they will digress ... and I think > that is ok.. > > --Udo > > > > On 1/19/17 13:05, John Blum wrote: > >> I agree with @Dan on the geode-examples bit, but not for a modular Geode. >> So... >> >> It depends on whether you are releasing and publishing separate artifacts >> to Maven Central (or Bintray and the like) as features are developed/bugs >> are fixed (i.e. CI/CD), then it is necessary to distinguish by version >> number to avoid collisions/conflicts and e able to consume the bits (which >> is much easier than anything else, to do from MC, when developing). >> >> However, when you start talking about Native Client vs. the >> geode-examples; >> those are 2 different animals! >> >> I would even go so far as to say the geode-examples could (and probably, >> should) live outside of the (core) Geode codebase. They do not need to be >> released with the product. They can, be based on a particular >> (curated/harmonized) set of Geode dependencies (using the Maven BOM I >> described earlier; Spring Data Examples does this, for instance, but SD >> Examples are not part of the SD Release Train). >> >> Or, how about, if I come up with another example, perhaps one based on a >> customer UC that highlights Geode is some particular way, addressing a >> very >> common, very important problem, which is independent of the Geode >> codebase, >> why should anyone have to wait for another Geode release for this example >> to be pushed? >> >> Like the Native Client, arguably, Spring Data Geode is closely tied to >> Apache Geode, yet releases separately and independently, at it's own >> cadence. That is also not to say 1 does not affect the other (Apache Geode >> most certainly affects SDG), but ironically, even though both are OSS >> projects with nearly the same "community" behind them, they are separate. >> >> >> On Thu, Jan 19, 2017 at 1:01 PM, Roman Shaposhnik <ro...@shaposhnik.org> >> wrote: >> >> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker <aba...@pivotal.io> >>> wrote: >>> >>>> On Jan 19, 2017, at 11:53 AM, Roman Shaposhnik <ro...@shaposhnik.org> >>>>> >>>> wrote: >>> >>>> On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith <dsm...@pivotal.io> wrote: >>>>> >>>>>> I wonder if we're trying to overcomplicate things there. I don't see >>>>>> >>>>> why >>> >>>> the geode-examples wouldn't use the same release schedule and version >>>>>> number as geode. >>>>>> >>>>>> The C++ and .NET clients are also somewhat tied to the version of >>>>>> geode >>>>>> that they support. As long as we can stick to a regular release >>>>>> >>>>> cadence, It >>> >>>> seems like those clients couldn't also follow the same release >>>>>> >>>>> schedule and >>> >>>> version numbers. >>>>>> >>>>> Huge +1 to the above! >>>>> >>>>> Thanks, >>>>> Roman. >>>>> >>>> >>>> Here’s a few examples of ASF projects with multiple repos for reference: >>>> >>>> - ActiveMQ >>>> https://github.com/apache?utf8=✓&q=activemq&type=&language= >>>> https://issues.apache.org/jira/secure/BrowseProjects.jspa# >>>> 11160 >>>> - Nifi >>>> https://github.com/apache?utf8=✓&q=nifi&type=&language= >>>> https://issues.apache.org/jira/secure/BrowseProjects.jspa# >>>> 13460 >>>> >>>> I agree that semi-coordinated releases from a single project community >>>> >>> make >>> >>>> sense—these are not independent things. Using lock-step versioning >>>> means >>>> we release everything together, even for patch releases right? And I’m >>>> assuming we would be doing separate release VOTE threads per repo. >>>> >>> An interesting thing to note is that despite multiple repos they still >>> release >>> a single source artifact: >>> https://www.apache.org/dist/activemq/5.13.5/ >>> https://www.apache.org/dist/nifi/1.1.1/ >>> >>> Thanks, >>> Roman. >>> >>> >> >> > -- -John john.blum10101 (skype)
