Re: [jgit-dev] Dropping storage.dht package

[Matthias Sohn <matthias.sohn@xxxxxxxxxxxxxx>]

2012/8/16 Dave Borowitz <dborowitz@xxxxxxxxxx>

Not to derail this entirely, but may I propose if we're revving to 3.0 that we consider moving some "public" classes that are really implementation details to internal packages? I know we've been annoyed in the past by being unable change things deep in, say, org.eclipse.jgit.transport that are "public APIs" by Eclipse's definition but nobody should really be depending on.

Of course, the bikeshedding discussion of what APIs should remain really public may take up so much time that we decide it's more effort than it's worth. But I thought I'd throw it out there.

On Wed, Aug 15, 2012 at 10:49 PM, Markus Duft <markus.duft@xxxxxxxxxx> wrote:

On 08/15/2012 01:20 AM, Shawn Pearce wrote:
> On Tue, Aug 14, 2012 at 3:36 PM, Chris Aniszczyk <caniszczyk@xxxxxxxxx> wrote:

[snip]

>
> OK. I will prepare a change within the next day or two to delete the
> DHT code. We may have to rev to 3.0 as a result of that change going
> in, but I really don't think anyone would really notice.

rev 3.0 would be great anyway for some other API breaking changes ([1], [2]). you could just vote them in then xD

[1] https://git.eclipse.org/r/5337
[2] https://git.eclipse.org/r/5373

considering the fact that Juno SR1 [1] is pretty soon (RC1 is next week, RC4 +3 is on Sept 19 

and GA on Sept 28) maybe it would be better to only deprecate DHT in the upcoming 2.1 

release and remove it in a next release 3.0 around December. We could fork stable-2.1

beginning of next week to prepare our RC1 contribution so on master DHT could be removed

after this is done. This would leave us a bit more time to get all the other breaking changes done.

I don't like the idea to bump the major version with every release ;-)

[1] http://wiki.eclipse.org/Juno/Simultaneous_Release_Plan#SR1

--

Matthias