If it's an easy revert, I think we'd be happy to leave it available but marked
deprecated with a flag that means you need to explicitly turn it on:
deprecated_annotatemore_support: yes
And include that in a 3.2 release.
Longer term though, the main reason for dropping it is that the annotations
code is a weird shape in order to support both old and new style ANNOTATEMORE
and METADATA. The plan was to clean up that mess once it no longer had to
support METADATA.
Samir: what's your plan for moving those users to something which supports
standard METADATA? Because the downside of keeping on supporting a legacy
ANNOTATEMORE in Cyrus is that somebody has to maintain that forever if you're
never planning to get off it, either you or everyone else touching that code!
Regards,
Bron.
On Wed, Sep 12, 2018, at 11:22, Dilyan Palauzov wrote:
> Hello Samir,
>
> if the opt-in ANNOTATEMORE feature is something that only you will use, as it
> currently looks like, I see no reason to bother others with it.
>
> Greetings
> Дилян
>
> On September 11, 2018 2:40:48 PM PDT, Samir Aguiar
> <samir.agu...@intra2net.com> wrote:
> >Hi Dilyan,
> >
> >On 09/11/2018 06:17 PM, Dilyan Palauzov wrote:
> >> it does not make sense to keep the ANNOTATEMORE code just for your
> >specific case.
> >>
> >> You are entitled to issue an updated client software dealing with
> >METADATA and ask users to update, or for your server to revert the
> >respective change.
> >
> >Yes, absolutely. We will need to revert that change and restore
> >ANNOTATEMORE support anyway since it's not possible at the moment for
> >all of our clients to upgrade.
> >
> >But I believe my question was ill-phrased. I actually meant to ask if
> >such revert, after done by us, would be accepted upstream as an opt-in
> >feature, or if the team has already decided to drop that implementation
> >for good.
> >
> >Kind regards,
> >Samir Aguiar
>
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
