<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 4:26 PM, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Answers inline (this is just my personal opinion)<br>
<div class=""><br>
On 2014-08-28, Matthias Wessendorf wrote:<br>
</div><div class="">> On Thu, Aug 28, 2014 at 4:03 PM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
><br>
> > I think this is something to fix at our SDKs,<br>
><br>
><br>
> like releasing 1.0.x (Server and SDKs), where the versioning is in?<br>
<br>
</div>For our releases tagged as 1.0.0, make it clear that UPS 1.0.0 IS<br>
required, also make it clear at our docs the reasons behind it.<br>
<div class=""><br>
><br>
> That's possible. And that way, we can say, why are you using 1.0.0, we<br>
> released 1.0.1 with (some sort of) fixes<br>
<br>
</div>For further releases of UPS server like 1.0.x, make it clear at our<br>
documentation with something like "This release requires the SDKs 1.0.x<br>
or superior" and make it clear the reasons behind it.<br>
<br>
Is not a perfect solution but....trade-offs.<br></blockquote><div>I would also prefer this approach </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">><br>
> -M<br>
><br>
><br>
> > and think about the legacy, that's the price to pay.<br>
> ><br>
> > The easy solution is to defaults to 1.0.0, but it doesn't seem correct.<br>
> > —<br>
> > abstractj<br>
> > PGP: 0x84DC9914<br>
> ><br>
> ><br>
> > On Thu, Aug 28, 2014 at 10:18 AM, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>><br>
> > wrote:<br>
> ><br>
> >> the problem is... our 1.0.0 SDKs do not specify a version :-)<br>
> >> so, they would than talk to the latest greatest, that does not work.<br>
> >><br>
> >> We need to have that in mind, when planing this.<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> On Thu, Aug 28, 2014 at 2:39 PM, Lucas Holmquist <<a href="mailto:lholmqui@redhat.com">lholmqui@redhat.com</a>><br>
> >> wrote:<br>
> >><br>
> >>> +1 on Accept headers and also using the latest and greatest if no<br>
> >>> version is specified/<br>
> >>><br>
> >>> i believe this is what github also does<br>
> >>><br>
> >>> On Aug 28, 2014, at 4:36 AM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
> >>><br>
> >>> On 2014-08-28, Matthias Wessendorf wrote:<br>
> >>><br>
> >>> On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>><br>
> >>> wrote:<br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius <<br>
> >>> <a href="mailto:daniel.bevenius@gmail.com">daniel.bevenius@gmail.com</a>> wrote:<br>
> >>><br>
> >>> If we go for the accept header and the consumer don't provide it, what<br>
> >>><br>
> >>> do we do ? Return an error or use implicitly the latest version ?<br>
> >>> Perhaps we can return the current version to not break any existing<br>
> >>> clients. New clients will need to provide an explicit version.<br>
> >>><br>
> >>> Why not but for how long do we return the "old" version by default ? (cf<br>
> >>> my questions around deprecation)<br>
> >>><br>
> >>><br>
> >>> yep - I am for that: looks like I forgot, and I think we had that on our<br>
> >>> face2face: no version == 1.0.0 (old)<br>
> >>><br>
> >>><br>
> >>> I vote for return the latest, instead of something old. And specify old<br>
> >>> versions if you want to.<br>
> >>><br>
> >>><br>
> >>> -M<br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> On 28 August 2014 09:25, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>> wrote:<br>
> >>><br>
> >>> Some questions :<br>
> >>><br>
> >>> * If we go for the accept header and the consumer don't provide it, what<br>
> >>> do we do ? Return an error or use implicitly the latest version ?<br>
> >>> * What will be our deprecation policy ? Do we want keep maintaining all<br>
> >>> the versions forever or let's say for 1.1 we still provide 1.0 and for<br>
> >>> 2.0<br>
> >>> we drop 1.0 ?<br>
> >>><br>
> >>> About the implementation :<br>
> >>> * I like the suggested CDI solution, if possible.<br>
> >>> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno<br>
> >>><br>
> >>> Sebi<br>
> >>> ps : I just read this blog post and it's really interesting :<br>
> >>> <a href="http://apiux.com/2013/05/14/api-versioning/" target="_blank">http://apiux.com/2013/05/14/api-versioning/</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius <<br>
> >>> <a href="mailto:daniel.bevenius@gmail.com">daniel.bevenius@gmail.com</a>> wrote:<br>
> >>><br>
> >>> +1 For using the Accept header to specify the version in the media type.<br>
> >>><br>
> >>><br>
> >>> On 28 August 2014 07:50, Matthias Wessendorf <<a href="mailto:matzew@apache.org">matzew@apache.org</a>> wrote:<br>
> >>><br>
> >>> Hello,<br>
> >>><br>
> >>> for the 1.1.x (master) we are potentially doing some changes on the<br>
> >>> Sender-API (see [1]).<br>
> >>><br>
> >>> However, for backwards compatibility we need to think about API<br>
> >>> versioning.<br>
> >>><br>
> >>> For REST APIs there are (IMO) two options:<br>
> >>> * accept header<br>
> >>> * URIs<br>
> >>><br>
> >>> On our Face2Face meeting we briefly talked about this and I think the<br>
> >>> "accept header" solution was the one that had most fans. I think QMX<br>
> >>> added<br>
> >>> that it is better for migration. One thing we were not clear on (I<br>
> >>> think):<br>
> >>> What are HATEOS defined semantics?<br>
> >>><br>
> >>><br>
> >>> Besides the what (headers vs. URI), I think we should think about<br>
> >>> possible implementations, to switch different versions.<br>
> >>><br>
> >>> Not sure, but wouldn't it be possible to inject an annotated<br>
> >>> SenderService into the RESTful endpoint, based on header values ?<br>
> >>> We could have a default impl (version 1.0.0) and an alternate one,<br>
> >>> that is injected if the accept header indicate API version 1.1<br>
> >>><br>
> >>> Any thoughts ?<br>
> >>><br>
> >>> -Matthias<br>
> >>><br>
> >>><br>
> >>> [1]<br>
> >>> <a href="http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html" target="_blank">http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html</a><br>
> >>><br>
> >>> --<br>
> >>> Matthias Wessendorf<br>
> >>><br>
> >>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> >>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> >>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> aerogear-dev mailing list<br>
> >>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> aerogear-dev mailing list<br>
> >>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> aerogear-dev mailing list<br>
> >>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> aerogear-dev mailing list<br>
> >>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> aerogear-dev mailing list<br>
> >>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> --<br>
> >>> Matthias Wessendorf<br>
> >>><br>
> >>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> >>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> >>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> aerogear-dev mailing list<br>
> >>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>> --<br>
> >>><br>
> >>> abstractj<br>
> >>> PGP: 0x84DC9914<br>
> >>> _______________________________________________<br>
> >>> aerogear-dev mailing list<br>
> >>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >>><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> aerogear-dev mailing list<br>
> >>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >>><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Matthias Wessendorf<br>
> >><br>
> >> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> >> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> >> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
> >><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Matthias Wessendorf<br>
><br>
> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
<br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></div></div></blockquote></div><br></div></div>