On Mon, 20 Jan 2014 13:41:23 +0100

Matthias Wessendorf <matzew@apache.org> wrote:

> On Monday, January 20, 2014, Karel Piwko <kpiwko@redhat.com> wrote:
>
> > On Mon, 20 Jan 2014 13:17:00 +0100

> > Matthias Wessendorf <matzew@apache.org <javascript:;>> wrote:
> >
> > > On Monday, January 20, 2014, Karel Piwko <kpiwko@redhat.com<javascript:;>>

> > wrote:
> > >
> > > > On Mon, 20 Jan 2014 12:27:22 +0100

> > > > Matthias Wessendorf <matzew@apache.org <javascript:;> <javascript:;>>

> > wrote:
> > > >
> > > > > On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko

> > > > > <kpiwko@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.

>
>
>
>
>
> >
> > >
> > >
> > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > 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@lists.jboss.org <javascript:;> <javascript:;>

> > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > _______________________________________________
> > > > aerogear-dev mailing list

> > > > aerogear-dev@lists.jboss.org <javascript:;> <javascript:;>

> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> > > >
> > >
> > >
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev@lists.jboss.org <javascript:;>
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
>
>

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev