On Mon, Jan 20, 2014 at 2:06 PM, Karel Piwko <kpiwko(a)redhat.com> wrote:
On Mon, 20 Jan 2014 13:41:23 +0100
Matthias Wessendorf <matzew(a)apache.org> wrote:
> On Monday, January 20, 2014, Karel Piwko <kpiwko(a)redhat.com> wrote:
>
> > On Mon, 20 Jan 2014 13:17:00 +0100
> > Matthias Wessendorf <matzew(a)apache.org <javascript:;>> wrote:
> >
> > > On Monday, January 20, 2014, Karel Piwko <kpiwko(a)redhat.com
<javascript:;>>
> > wrote:
> > >
> > > > On Mon, 20 Jan 2014 12:27:22 +0100
> > > > Matthias Wessendorf <matzew(a)apache.org <javascript:;>
<javascript:;>>
> > wrote:
> > > >
> > > > > On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko
> > > > > <kpiwko(a)redhat.com
<javascript:;><javascript:;>>
> > > > wrote:
> > > > >
> > > > > > > +1 on postponing to a later point. If ready by April,
should
be
> > fine
> > > > as
> > > > > > > well (my opinion). Bruno had a good point, that the
postponed
> > release
> > > > > > > should not stop us from releasing (unstable) snapshots
for
> > testing
> > > > > > reasons.
> > > > > > > I like that: Release often, release early.
> > > > > >
> > > > > > What is actually an (unstable) snapshot? Could you shed
more
light
> > on
> > > > that?
> > > > > >
> > > > >
> > > > > I'd say a regular snapshot, from master branch, released to
the
> > snapshot
> > > > > repo
> > > >
> > > > That's good until another project(s) will rely on it. You update
> > snaphot
> > > > and
> > > > other projects will get broken without any option to avoid that. It
> > would
> > > > be
> > > > much better to make snapshots stable in time, as I described in
> > previous
> > > > email.
> > >
> > >
> > > Well, this is all early and understood, not why thats a problem, when
> > > DEVELOPING something...
> > >
> >
> > That's right. But when testing something it is a problem. We don't
have a
> > bandwidth to update tests every time something get's broken due to new
> > SNAPSHOT being released to repository. OTOH, updating tests after all
> > projects
> > are released as Final is too late. I'm looking for some model in
between
> > to let
> > us keep pace with devs.
>
>
> Well, when something is under heavy development, like ALL the sync
things,
> it makes sense to do snapshots; when things(e.g protocol, server etc)
> changes, sure we will update our unit tests and adjust the clients; thats
> basically the development of sync;
>
> You talking about integration tests or what?
Exactly. Integration tests, especially that ones that test more Aerogear
projects combined together.
well, to be honest, as long as we don't really know what the server is, how
the client APIs look like (e.g 0.0.1-SNAPSHOT, 0.0.2-SNAPSHOT) it's
pointless to actually do that.
>
>
>
>
>
> >
> > >
> > >
> > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Namely, is the "snapshot" a set of micro/minor
releases of
Aerogear
> > > > > > projects?
> > > > > > Or do you plan to release every Aerogear project as
-SNAPSHOT?
Or
> > > > > > introducing
> > > > > >
-milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like
into
> > > > version
> > > > > > strings?
> > > > > >
> > > > > > I don't think 2/ option is a good idea, especially if
SNAPSHOTs are
> > > > > > released
> > > > > > early & often. That would be a maintenance/testing
nightmare,
if
> > > > various
> > > > > > SNAPSHOTs of the same project cannot be distinguished from
each
> > other
> > > > and
> > > > > > used
> > > > > > within other projects.
> > > > > >
> > > > > > Karel
> > > > > > _______________________________________________
> > > > > > aerogear-dev mailing list
> > > > > > aerogear-dev(a)lists.jboss.org <javascript:;>
<javascript:;>
> > > > > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list
> > > > aerogear-dev(a)lists.jboss.org <javascript:;>
<javascript:;>
> > > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > >
> > >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org <javascript:;>
> >
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