accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [DISCUSS] Pulling out the examples
Date Fri, 19 Feb 2016 00:46:11 GMT
On Thu, Feb 18, 2016 at 7:37 PM Josh Elser <> wrote:

> I'd like to see some process put into place to mitigate "bit-rot". If
> the examples don't live in the "main" repository, how do we make sure
> they don't get ignored and become dead or "bad" code?
> For questions at the foreground now:
I also spoke to Keith about this, and here's some answers we tossed around:

> * Can we set up new CI jobs that build the new examples repo against
> SNAPSHOT repos?

Yes, and I think it's something we'd want to do.

> * How do we vet the examples for a release?

I think we should think about this more as the examples are vetting the
release. If we do a release which breaks the examples, we haven't been
doing our job with Semver.

I would like to see us annotate the examples with the earliest version they
were designed to run against, and use them to ensure we don't break semver.
For major releases, which breaks an example, we can add an optional
annotation for that, too. (At which point, we'd probably create a new
version of the same example, for those newer versions of Accumulo.)

> * Does a release of Accumulo "proper" imply a release of the examples?
> Or are they two separate things?

Separate. Definitely separate. I think that's the main thing driving this
idea. With semver, we shouldn't be having examples tied to specific
releases... they should work on a well-documented range of versions. We can
use the examples to prove stability of the public API.

> * What versions of Accumulo would we expect these examples to build
> against? Anything that isn't EOL'ed?
I would say a range we annotate them with, starting with the first minor
release it works against, and optionally ending at some breaking major
version. Since they're examples, I don't think we'd need to EOL them when
we EOL a version of Accumulo... we'd just need to ensure they are
documented for what versions they serve to example.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message