accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <busbey...@clouderagovt.com>
Subject Re: remove wikisearch from 1.4.x development?
Date Tue, 19 Nov 2013 14:59:44 GMT
On Tue, Nov 19, 2013 at 8:05 AM, Christopher <ctubbsii@apache.org> wrote:

> It seems like consensus was not really reached on the issue. I don't
> have a very strong opinion on this, but it does seem that changing the
> packaging for 1.4.x for a bugfix release in a major way like this is
> not really a nice thing to do to users.
>
> There's a risk users will have based code agaisnt 1.4.x on this
> example, and it wouldn't be good to break it. At the very least,
> keeping the example in there (and not modifying the way it uses the
> public API), acts as a test, to ensure that we don't make any changes
> that makes 1.4.x user code incompatible with the latest 1.4.x
> development, when they've based their code on what we've suggested
> through our examples.
>
> Since a version of wikisearch has been released with 1.4.4, and we
> already have a separate git repo for wikisearch development, I would
> be okay dropping it from the main repo's 1.4.5-SNAPSHOT branch, if we
> were willing to continue releasing wikisearch from its own repo to
> keep it working with the latest 1.4.x whenever we release accumulo
> 1.4.x.
>
> In other words, it doesn't have to exist in the 1.4.x branch, but it
> should still follow the 1.4.x releases, being released from the
> contrib repo, keeping in line with the packaging precedent for the 1.4
> series.
>
>
>
We would expressly not being claiming that wikisearch is a part of our
public API, correct?

What kind of testing would be involved for doing a release of the
wikisearch contrib? Just unit tests as is done with it as part of the 1.4.x
branch?

Would the releases from the contrib repo need to have version numbers that
match the 1.4.x line, or would a compatibility statement for each release
be sufficient?

-- 
Sean

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