Bug#859306: unblock: django-anymail/0.8-2
On Wednesday, April 12, 2017 08:33:57 PM Ivo De Decker wrote:
> Control: tags -1 moreinfo
>
> Hi,
>
> On Sat, Apr 01, 2017 at 05:32:18PM -0400, Scott Kitterman wrote:
> > Please unblock package django-anymail
> >
> > This is a pre-upload request. django-anymail 0.8-1 is currently in
> > in experimental. If this is approved, I'll upload to unstable with no
> > changes other than the new debian/changelog entry.
> >
> > This is outside the normal scope of things that would be approved, but
> > given the nature of the package, I believe letting the new version into
> > stretch is a resonable thing to do. django-anymail is a contrib package
> > that exists to make it easier to integrate with various proprietary email
> > sending services (the code itself is Free).
> >
> > The new version adds support for the new Sendgrid v3 API, but maintains v2
> > support through a new v2 specific backend. I am including a separate diff
> > of the 0.7 v2 backend (which was just called sendgrid) and the 0.8 v2
> > backend (now called sendgrid_v2) to make it easier to see that the
> > existing code is not much changed.
> >
> > This version includes some changes from 0.7 that are incompatible. This
> > is a new package and so I think we are better off updating to provide the
> > newer code in this release and avoid upgrade problems in Buster or if
> > newer versions are backported to stretch-backports.
>
> The fact that upstream did some changes which make upgrades from the current
> version difficult doesn't seem like a good reason to allow changes into
> testing. Is there any reason to believe that upstream will be more sensible
> in the future? Also, if it's difficult to avoid upgrade problems in buster,
> wouldn't it be better to not have this package in stretch?
My impression is that the refactoring that led to the upgrading complication
are a one time issue. As I have followed this upstream, they have generally
been very sensible about such things, but in this case I think it was not
easily avoidable and unlikely to come up again (which is why I'm asking to get
this into Stretch).
So far the services that this package integrate with have been very good about
backward compatibility (e.g. in this current case there is a new Sendgrid v3
API and the older, v2, API is still maintained. Unlike many packages that
attempt to track unstable, poorly maintained APIs, I believe this package is
suitable for a stable release.
I have plenty of time to solve the upgradability issue for Buster if the RT
decides not to accept this, so I don't think that should prevent it staying in
Stretch. I am hoping you'll accept the version bump as it's the easiest way
to do it.
I recognize this request is outside the normal scope of what's accepted.
Given that the only purpose of this package is for integration with external
APIs and it's in contrib, I was hoping for an exception for this case.
I hope that clarifies things. If not, please let me know.
Scott K
Reply to: