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.
