+1 On Wed, Jul 3, 2013 at 3:37 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: Hi, I think it does make sense to track all the items for SimplePush (server and client) in a separated JIRA. That way we could have a more straightforward process of individual release, tracking at the right source etc. The integration between UP and SP would be still tracked at AGPUSH, but that's really just one or two java classes :-) Motivation: I think that UP and SP are pretty different. Regarding SP, I think it does make sense to capture that in a different instance: * SimplePush works standalone or in combination with WildFly/vert.x --> different targets, different dependencies, different "envirnoments" * SimplePush is based on a spec (Moz-specific spec). --> The server (and the client) should reflect that with different cycles/releases, to be more fine grain. * Independency --> A release of a new version of SimplePush (based on a Netty bug, for instance), should not be treated in a "Push release", while the UnifiedPush server has no code changes at all. (vice versa) For the name: AGSIMPLEPUSH The AGPUSH will stay to "catch" all the UnifiedPush items. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

+1 On 3 July 2013 15:39, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: #agreed On Jul 3, 2013, at 9:38 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > +1 > > > On Wed, Jul 3, 2013 at 3:37 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > Hi, > > I think it does make sense to track all the items for SimplePush (server and client) in a separated JIRA. That way we could have a more straightforward process of individual release, tracking at the right source etc. > > The integration between UP and SP would be still tracked at AGPUSH, but that's really just one or two java classes :-) > > > Motivation: > I think that UP and SP are pretty different. Regarding SP, I think it does make sense to capture that in a different instance: > * SimplePush works standalone or in combination with WildFly/vert.x > --> different targets, different dependencies, different "envirnoments" > * SimplePush is based on a spec (Moz-specific spec). > --> The server (and the client) should reflect that with different cycles/releases, to be more fine grain. > * Independency > --> A release of a new version of SimplePush (based on a Netty bug, for instance), should not be treated in a "Push release", while the UnifiedPush server has no code changes at all. (vice versa) > > For the name: AGSIMPLEPUSH > > The AGPUSH will stay to "catch" all the UnifiedPush items. > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

how do you track different versions (e.g. based on Protocol/JS API changes) ?

or the other way around: if GCM/APNs changes.... and a new release comes out... the "UnifiedPush" would increase the number, not really good reflecting the state of SimplePush. IMO a separate JIRA allows just more fine-tuning, on the different components (especially two servers). On Wed, Jul 3, 2013 at 5:41 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: Hmmm, why wouldn't this work just be captured in AGJS and keep the UP SP related work in AGPUSH … not sure if another JIRA project is necessary. On Jul 3, 2013, at 8:49 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: > +1 > > > On 3 July 2013 15:39, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > #agreed > > On Jul 3, 2013, at 9:38 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > >> +1 >> >> >> On Wed, Jul 3, 2013 at 3:37 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> Hi, >> >> I think it does make sense to track all the items for SimplePush (server and client) in a separated JIRA. That way we could have a more straightforward process of individual release, tracking at the right source etc. >> >> The integration between UP and SP would be still tracked at AGPUSH, but that's really just one or two java classes :-) >> >> >> Motivation: >> I think that UP and SP are pretty different. Regarding SP, I think it does make sense to capture that in a different instance: >> * SimplePush works standalone or in combination with WildFly/vert.x >> --> different targets, different dependencies, different "envirnoments" >> * SimplePush is based on a spec (Moz-specific spec). >> --> The server (and the client) should reflect that with different cycles/releases, to be more fine grain. >> * Independency >> --> A release of a new version of SimplePush (based on a Netty bug, for instance), should not be treated in a "Push release", while the UnifiedPush server has no code changes at all. (vice versa) >> >> For the name: AGSIMPLEPUSH >> >> The AGPUSH will stay to "catch" all the UnifiedPush items. >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

yeah, if SP changes protocol, and the server needs to ract on it. Or netty is broken (and we need a fix), it's odd to increase the version nr, for the Unified Push as well

-M On Wed, Jul 3, 2013 at 5:57 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Jul 3, 2013, at 10:47 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > how do you track different versions (e.g. based on Protocol/JS API changes) ? We would release an AGJS version. SimplePush client is part of AGJS so I would expect it to be in that JIRA. That said, I just realized you may be talking about the SPS server. If that is the case, a separate JIRA for the SPS server makes sense. > or the other way around: if GCM/APNs changes.... and a new release comes out... the "UnifiedPush" would increase the number, not really good reflecting the state of SimplePush. > > IMO a separate JIRA allows just more fine-tuning, on the different components (especially two servers). > > > On Wed, Jul 3, 2013 at 5:41 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > Hmmm, why wouldn't this work just be captured in AGJS and keep the UP SP related work in AGPUSH … not sure if another JIRA project is necessary. > > On Jul 3, 2013, at 8:49 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; wrote: > >> +1 >> >> >> On 3 July 2013 15:39, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> #agreed >> >> On Jul 3, 2013, at 9:38 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >>> +1 >>> >>> >>> On Wed, Jul 3, 2013 at 3:37 PM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> Hi, >>> >>> I think it does make sense to track all the items for SimplePush (server and client) in a separated JIRA. That way we could have a more straightforward process of individual release, tracking at the right source etc. >>> >>> The integration between UP and SP would be still tracked at AGPUSH, but that's really just one or two java classes :-) >>> >>> >>> Motivation: >>> I think that UP and SP are pretty different. Regarding SP, I think it does make sense to capture that in a different instance: >>> * SimplePush works standalone or in combination with WildFly/vert.x >>> --> different targets, different dependencies, different "envirnoments" >>> * SimplePush is based on a spec (Moz-specific spec). >>> --> The server (and the client) should reflect that with different cycles/releases, to be more fine grain. >>> * Independency >>> --> A release of a new version of SimplePush (based on a Netty bug, for instance), should not be treated in a "Push release", while the UnifiedPush server has no code changes at all. (vice versa) >>> >>> For the name: AGSIMPLEPUSH >>> >>> The AGPUSH will stay to "catch" all the UnifiedPush items. >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Late to the party, but +1 as well - created AEROGEAR-1279 to track -Jay On Jul 3, 2013, at 12:07 PM, Kris Borchers wrote: On Jul 3, 2013, at 11:00 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: yeah, if SP changes protocol, and the server needs to ract on it. Or netty is broken (and we need a fix), it's odd to increase the version nr, for the Unified Push as well Makes sense +1 -M On Wed, Jul 3, 2013 at 5:57 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jul 3, 2013, at 10:47 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > how do you track different versions (e.g. based on Protocol/JS API > changes) ? > > > We would release an AGJS version. SimplePush client is part of AGJS so I > would expect it to be in that JIRA. That said, I just realized you may be > talking about the SPS server. If that is the case, a separate JIRA for the > SPS server makes sense. > > or the other way around: if GCM/APNs changes.... and a new release comes > out... the "UnifiedPush" would increase the number, not really good > reflecting the state of SimplePush. > > IMO a separate JIRA allows just more fine-tuning, on the different > components (especially two servers). > > > On Wed, Jul 3, 2013 at 5:41 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> Hmmm, why wouldn't this work just be captured in AGJS and keep the UP SP >> related work in AGPUSH … not sure if another JIRA project is necessary. >> >> On Jul 3, 2013, at 8:49 AM, Daniel Bevenius <daniel.bevenius(a)gmail.com&gt; >> wrote: >> >> +1 >> >> >> On 3 July 2013 15:39, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >>> #agreed >>> >>> On Jul 3, 2013, at 9:38 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; >>> wrote: >>> >>> +1 >>> >>> >>> On Wed, Jul 3, 2013 at 3:37 PM, Matthias Wessendorf <matzew(a)apache.org&gt;wrote: >>> >>>> Hi, >>>> >>>> I think it does make sense to track all the items for SimplePush >>>> (server and client) in a separated JIRA. That way we could have a more >>>> straightforward process of individual release, tracking at the right source >>>> etc. >>>> >>>> The integration between UP and SP would be still tracked at AGPUSH, >>>> but that's really just one or two java classes :-) >>>> >>>> >>>> Motivation: >>>> I think that UP and SP are pretty different. Regarding SP, I think it >>>> does make sense to capture that in a different instance: >>>> * SimplePush works standalone or in combination with WildFly/vert.x >>>> --> different targets, different dependencies, different "envirnoments" >>>> * SimplePush is based on a spec (Moz-specific spec). >>>> --> The server (and the client) should reflect that with different >>>> cycles/releases, to be more fine grain. >>>> * Independency >>>> --> A release of a new version of SimplePush (based on a Netty bug, >>>> for instance), should not be treated in a "Push release", while the >>>> UnifiedPush server has no code changes at all. (vice versa) >>>> >>>> For the name: AGSIMPLEPUSH >>>> >>>> The AGPUSH will stay to "catch" all the UnifiedPush items. >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev