You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Anthony Baker <ab...@pivotal.io> on 2017/01/19 15:55:14 UTC
JIRA versions and multiple repos
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
Re: JIRA versions and multiple repos
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
+1 sounds good
On 1/19/17 09:02, John Blum wrote:
> 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 <ab...@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 \u2018Fix version\u2019 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
>> \u2018geode-examples-0.1\u2019. We could also ask for a JIRA project for each repo.
>> Thoughts?
>>
>> More stuff:
>>
>> - GEODE-2318 didn\u2019t 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\u2019s or email notifications let me know.
>>
>> Anthony
>>
>> [1] https://github.com/apache/geode-examples/blob/develop/
>> gradle.properties#L17
>>
>>
>
Re: JIRA versions and multiple repos
Posted by John Blum <jb...@pivotal.io>.
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 <ab...@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)
Re: JIRA versions and multiple repos
Posted by Kirk Lund <kl...@apache.org>.
Why are we trying to use separate repos for examples and native client? Is
the main driver for this simply to use a different build tool than Gradle
(at least for native client)?
I would think a submodule could be ignored by Gradle and that submodule
could have its own unrelated build too (cmake or whatever). If we really
wanted to, there's probably some way to make Gradle fire off other build
tools as well
On Thu, Jan 19, 2017 at 3:03 PM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> Btw, I've just confirmed that NiFi considers those subprojects
> (AKA separate communities).
>
> In fact ASF board asked them for that very clarification recently
>
> Thanks,
> Roman.
>
> On Thu, Jan 19, 2017 at 2:27 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> > On Thu, Jan 19, 2017 at 2:23 PM, Anthony Baker <ab...@pivotal.io>
> wrote:
> >>
> >>> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >>>
> >>> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker <abaker@pivotal.io
> <ma...@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 <ds...@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/activemq/5.13.5/>
> >>> https://www.apache.org/dist/nifi/1.1.1/ <
> https://www.apache.org/dist/nifi/1.1.1/>
> >>>
> >>> Thanks,
> >>> Roman.
> >>
> >> FWIW, it looks to me like these projects are doing releases from each
> of their repos:
> >>
> >> https://www.apache.org/dist/activemq/activemq-apollo/1.7.1/
> >> https://www.apache.org/dist/activemq/activemq-artemis/1.5.1/
> >> https://www.apache.org/dist/activemq/activemq-cpp/3.9.3/
> >
> > I'm actually not sure what the status of these is sine I can't seem to
> find
> > those on the official download page:
> > http://activemq.apache.org/download.html
> >
> >> https://www.apache.org/dist/nifi/minifi/0.1.0/
> >> https://www.apache.org/dist/nifi/nifi-minifi-cpp/0.1.0/
> >> https://www.apache.org/dist/nifi/nifi-nar-maven-plugin-1.1.0/
> >
> > Ditt for NiFi. In fact, as far as minifi is concerned -- I'm pretty
> > sure it is still
> > considered to be 'do not try this at home'.
> >
> >> Which is not to say that is how Geode should operate, but I’m just
> looking for precedent and prior art :-)
> >
> > But that's my point -- I don't think it constitutes prior art. In fact
> > the only prior art I'm
> > aware of would be Apache Commons (which actually does explicitly split
> > the community).
> >
> > Thanks,
> > Roman.
>
Re: JIRA versions and multiple repos
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Btw, I've just confirmed that NiFi considers those subprojects
(AKA separate communities).
In fact ASF board asked them for that very clarification recently
Thanks,
Roman.
On Thu, Jan 19, 2017 at 2:27 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Thu, Jan 19, 2017 at 2:23 PM, Anthony Baker <ab...@pivotal.io> wrote:
>>
>>> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>>
>>> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker <abaker@pivotal.io <ma...@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 <ds...@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/activemq/5.13.5/>
>>> https://www.apache.org/dist/nifi/1.1.1/ <https://www.apache.org/dist/nifi/1.1.1/>
>>>
>>> Thanks,
>>> Roman.
>>
>> FWIW, it looks to me like these projects are doing releases from each of their repos:
>>
>> https://www.apache.org/dist/activemq/activemq-apollo/1.7.1/
>> https://www.apache.org/dist/activemq/activemq-artemis/1.5.1/
>> https://www.apache.org/dist/activemq/activemq-cpp/3.9.3/
>
> I'm actually not sure what the status of these is sine I can't seem to find
> those on the official download page:
> http://activemq.apache.org/download.html
>
>> https://www.apache.org/dist/nifi/minifi/0.1.0/
>> https://www.apache.org/dist/nifi/nifi-minifi-cpp/0.1.0/
>> https://www.apache.org/dist/nifi/nifi-nar-maven-plugin-1.1.0/
>
> Ditt for NiFi. In fact, as far as minifi is concerned -- I'm pretty
> sure it is still
> considered to be 'do not try this at home'.
>
>> Which is not to say that is how Geode should operate, but I’m just looking for precedent and prior art :-)
>
> But that's my point -- I don't think it constitutes prior art. In fact
> the only prior art I'm
> aware of would be Apache Commons (which actually does explicitly split
> the community).
>
> Thanks,
> Roman.
Re: JIRA versions and multiple repos
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Jan 19, 2017 at 2:23 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
>> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>>
>> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker <abaker@pivotal.io <ma...@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 <ds...@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/activemq/5.13.5/>
>> https://www.apache.org/dist/nifi/1.1.1/ <https://www.apache.org/dist/nifi/1.1.1/>
>>
>> Thanks,
>> Roman.
>
> FWIW, it looks to me like these projects are doing releases from each of their repos:
>
> https://www.apache.org/dist/activemq/activemq-apollo/1.7.1/
> https://www.apache.org/dist/activemq/activemq-artemis/1.5.1/
> https://www.apache.org/dist/activemq/activemq-cpp/3.9.3/
I'm actually not sure what the status of these is sine I can't seem to find
those on the official download page:
http://activemq.apache.org/download.html
> https://www.apache.org/dist/nifi/minifi/0.1.0/
> https://www.apache.org/dist/nifi/nifi-minifi-cpp/0.1.0/
> https://www.apache.org/dist/nifi/nifi-nar-maven-plugin-1.1.0/
Ditt for NiFi. In fact, as far as minifi is concerned -- I'm pretty
sure it is still
considered to be 'do not try this at home'.
> Which is not to say that is how Geode should operate, but I’m just looking for precedent and prior art :-)
But that's my point -- I don't think it constitutes prior art. In fact
the only prior art I'm
aware of would be Apache Commons (which actually does explicitly split
the community).
Thanks,
Roman.
Re: JIRA versions and multiple repos
Posted by Anthony Baker <ab...@pivotal.io>.
> On Jan 19, 2017, at 1:01 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker <abaker@pivotal.io <ma...@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 <ds...@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/activemq/5.13.5/>
> https://www.apache.org/dist/nifi/1.1.1/ <https://www.apache.org/dist/nifi/1.1.1/>
>
> Thanks,
> Roman.
FWIW, it looks to me like these projects are doing releases from each of their repos:
https://www.apache.org/dist/activemq/activemq-apollo/1.7.1/
https://www.apache.org/dist/activemq/activemq-artemis/1.5.1/
https://www.apache.org/dist/activemq/activemq-cpp/3.9.3/
https://www.apache.org/dist/nifi/minifi/0.1.0/
https://www.apache.org/dist/nifi/nifi-minifi-cpp/0.1.0/
https://www.apache.org/dist/nifi/nifi-nar-maven-plugin-1.1.0/
Which is not to say that is how Geode should operate, but I’m just looking for precedent and prior art :-)
Anthony
Re: JIRA versions and multiple repos
Posted by John Blum <jb...@pivotal.io>.
+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 <uk...@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 <ab...@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 <ds...@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)
Re: JIRA versions and multiple repos
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
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 <ab...@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 <ds...@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\u2019s a few examples of ASF projects with multiple repos for reference:
>>>
>>> - ActiveMQ
>>> https://github.com/apache?utf8=\u2713&q=activemq&type=&language=
>>> https://issues.apache.org/jira/secure/BrowseProjects.jspa#11160
>>> - Nifi
>>> https://github.com/apache?utf8=\u2713&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\u2014these are not independent things. Using lock-step versioning means
>>> we release everything together, even for patch releases right? And I\u2019m
>>> 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.
>>
>
>
Re: JIRA versions and multiple repos
Posted by John Blum <jb...@pivotal.io>.
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 <ab...@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 <ds...@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)
Re: JIRA versions and multiple repos
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Jan 19, 2017 at 12:54 PM, Anthony Baker <ab...@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 <ds...@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.
Re: JIRA versions and multiple repos
Posted by Anthony Baker <ab...@pivotal.io>.
> 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 <ds...@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.
Anthony
Re: JIRA versions and multiple repos
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Jan 19, 2017 at 11:21 AM, Dan Smith <ds...@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.
Re: JIRA versions and multiple repos
Posted by Michael William Dodge <md...@pivotal.io>.
Do any of the users of what we call the C++ and .NET clients view them as libraries that provide an API? (As opposed to standalone applications.) If so, it would seem that they would expect the API libraries to move in step with the server releases. If the majority of the functionality in the C++ and .NET libraries is dependent on functionality in the server, having a divergence in versions amongst them might be a bit surprising. To put it another way, will the C++ or .NET clients be releasing significant functionality without support for that functionality in the server?
Sarge
> On 19 Jan, 2017, at 11:58, Jacob Barrett <jb...@pivotal.io> wrote:
>
> I think I agree. We should try the same release cycle for all components
> until we find we can't.
>
> -Jake
>
> On Thu, Jan 19, 2017 at 11:21 AM Dan Smith <ds...@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.
>>
>> -Dan
>>
>> On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker <ab...@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
>>>
>>>
>>
Re: JIRA versions and multiple repos
Posted by Ernest Burghardt <eb...@pivotal.io>.
+1 for keeping it Simple
On Thu, Jan 19, 2017 at 11:59 AM, Swapnil Bawaskar <sb...@pivotal.io>
wrote:
> +1
>
> On Thu, Jan 19, 2017 at 11:58 AM, Jacob Barrett <jb...@pivotal.io>
> wrote:
>
> > I think I agree. We should try the same release cycle for all components
> > until we find we can't.
> >
> > -Jake
> >
> > On Thu, Jan 19, 2017 at 11:21 AM Dan Smith <ds...@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.
> > >
> > > -Dan
> > >
> > > On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker <ab...@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
> > > >
> > > >
> > >
> >
>
Re: JIRA versions and multiple repos
Posted by Swapnil Bawaskar <sb...@pivotal.io>.
+1
On Thu, Jan 19, 2017 at 11:58 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> I think I agree. We should try the same release cycle for all components
> until we find we can't.
>
> -Jake
>
> On Thu, Jan 19, 2017 at 11:21 AM Dan Smith <ds...@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.
> >
> > -Dan
> >
> > On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker <ab...@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
> > >
> > >
> >
>
Re: JIRA versions and multiple repos
Posted by Jacob Barrett <jb...@pivotal.io>.
I think I agree. We should try the same release cycle for all components
until we find we can't.
-Jake
On Thu, Jan 19, 2017 at 11:21 AM Dan Smith <ds...@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.
>
> -Dan
>
> On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker <ab...@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
> >
> >
>
Re: JIRA versions and multiple repos
Posted by Dan Smith <ds...@pivotal.io>.
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.
-Dan
On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker <ab...@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
>
>
Re: JIRA versions and multiple repos
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
What you're talking about makes sense -- but it is mechanics. What
I'm talking about is a community composition. E.g. if we truly believe
that communities of developers around, lets say core Java Geode
and Native Client are non-overlapping (or there's very little overlap)
we need to recognize this fact by running them as separate ASF
projects. The mechanics will flow from the answering the community
composition question.
Thanks,
Roman.
On Thu, Jan 19, 2017 at 9:20 AM, John Blum <jb...@pivotal.io> wrote:
> Not sure if ASF has, or uses the same concept, but this could easily be
> handled with a GitHub "organization" encompassing 1 or more repos (for
> example... https://github.com/reactor).
>
> Of course, you could organize the source, and in particular, the Geode
> "modules" anyway you like, for example, as 1 repo. It's just more
> common/natural to use separate repos for independently releasable
> artifacts. In that way, the community does not seem as fragmented, rather
> organized into teams around particular concerns (aka modules/features).
> Native Client is perhaps the best example of this since it encompasses
> different tools and different languages but with a common "purpose".
>
> More food for thought.
>
> -j
>
>
> On Thu, Jan 19, 2017 at 9:12 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
>> On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker <ab...@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.
>>
>> This is the slippery slope I was alluding to. If the repos, releases,
>> etc. are asynchronous
>> in the eyes of ASF it strongly suggests that communities are
>> asynchronous as well. Which
>> means you're really two separate ASF projects. Which may, very well,
>> be the case I just
>> wanted to point it out.
>>
>> Thanks,
>> Roman.
>>
>
>
>
> --
> -John
> john.blum10101 (skype)
Re: JIRA versions and multiple repos
Posted by John Blum <jb...@pivotal.io>.
Not sure if ASF has, or uses the same concept, but this could easily be
handled with a GitHub "organization" encompassing 1 or more repos (for
example... https://github.com/reactor).
Of course, you could organize the source, and in particular, the Geode
"modules" anyway you like, for example, as 1 repo. It's just more
common/natural to use separate repos for independently releasable
artifacts. In that way, the community does not seem as fragmented, rather
organized into teams around particular concerns (aka modules/features).
Native Client is perhaps the best example of this since it encompasses
different tools and different languages but with a common "purpose".
More food for thought.
-j
On Thu, Jan 19, 2017 at 9:12 AM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker <ab...@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.
>
> This is the slippery slope I was alluding to. If the repos, releases,
> etc. are asynchronous
> in the eyes of ASF it strongly suggests that communities are
> asynchronous as well. Which
> means you're really two separate ASF projects. Which may, very well,
> be the case I just
> wanted to point it out.
>
> Thanks,
> Roman.
>
--
-John
john.blum10101 (skype)
Re: JIRA versions and multiple repos
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Thu, Jan 19, 2017 at 7:55 AM, Anthony Baker <ab...@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.
This is the slippery slope I was alluding to. If the repos, releases,
etc. are asynchronous
in the eyes of ASF it strongly suggests that communities are
asynchronous as well. Which
means you're really two separate ASF projects. Which may, very well,
be the case I just
wanted to point it out.
Thanks,
Roman.