KIMAP2

[Christian Mollekopf]

Just to clarify, I'm not looking to merge right now.
I'm trying to outline my plans so we can discuss what works best for
everyone.

If kimap goes to frameworks (unlike kimap2) there very well might be no
porting for some time to come,
although that is clearly not what I recommend.
In terms of porting the API changes aren't very large, so it should't be
 a huge effort, but I can go into more detail if necessary.

Anyways, we'll certainly wait with for the Applications 16.12 branching,
an d I'll also wait until we have reached a conclusion on how to move
forward, this was just a proposal.

Cheers,
Christian

On Tue, Nov 15, 2016, at 03:20 PM, Luca Beltrame wrote:
> Il giorno Tue, 15 Nov 2016 15:13:09 +0100
> Christian Mollekopf <chrigi_1 at fastmail.fm> ha scritto:
> 
> Hello,
> 
> > want to keep KIMAP around (I assume you do), I suggest we release it
> > from a stable branch "kimap", as I would like to move master to
> > kimap2. If that causes large problems with the way things are
> 
> From my opinion, what would be the only ready-user of KIMAP2? Kube?
> Then, I'm not part of PIM people and just a casual observer, but I'd
> suggest NOT to migrate master to kimap2 unless at least reviews to port
> the easy bits or a porting guide is published. 
> 
> IOW: I think that moving master to a lib without any users ported is a
> bad idea. But it is your (as in "PIM people") code.
> 
> And let's not forget the CI: this will likely break everything although
> the build metadata can be adjusted, probably.
> 
> Applications 16.12 is about to get branched... I would suggest *at the
> very least* to wait until feature freeze kicks in and stuff is branched
> before doing something like that. It would at least spare an additional
> branch.
> Email had 1 attachment:
> + Attachment2
>   1k (application/pgp-signature)